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0(57) Abstract: An electronic commerce system comprising: a series ofpoint of sale teiroinals providing for point of sale infonnaiion 
handling of a business; an interconnection network interconnecting the point of sale tcnninaJs to a central database facility, a central 
^ database facility (or storing information about each of the businesses for access by the operatois of the point of sale tenninals; and a 
^ series of service providers ioieiconnected to the cential databa.se facility for meeting requests issued by die point of sale temdnals. 
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An Internet E-Commerce System 

Field of the invention 

The present invcniion relates lo ihc field of Intcmci elecironic commerce and. in particular, discloses a hybrid e- 
commerce system having increased levels of funaionaliiy and opcrability. 

Background of tiie Invention 

Tradiiionally. businesses have carried oui activities utilising many differeni forms of communication. For example. 
Icilcrs. faxes and. more recently, c-mail have been traditionally used to place orders for the goods and services of a business. 

Recently, the Internet has been undergoing an explosive growth period. In panicular. the "World Wide Web" has 
provided a new avenue for the conduct of commercial transactions. This has lead to the concept of "E-commcrcc" in thai 
commercial transactions can be carried over the Internet so as to facilitate a more optintal form of business operation. In 
panicular it allows the direct selling of goods over the Imemet from the producer to the consumer. 

However, the utilisation of the World Wide Web often requires a high level of still in the creation of HTML pages. 
Java scripts etc.. in order to create appealing and auractive web pages having a high level of funaionaiity. Additionally, a large 
number of different programs and hardware are often required. For example, browsers, e-mail programs, fax machine or fax 
software, a HTML editor, an ftp program etc. 

Further, commcnual business arrangements also often require separate Electronic Funds Transfer Point of Sale 
facilities for the conduct of sales transactions which are often totally separate fn)m any Internet services. 

As a result businesses, in particular, small business, tend to have a reduced uptake of Internet type operations. 
Summary of tlie invention 

It is the object of the prescni invention to provide for an E-commcrce system having advantageous attributes. 

In accordance wiih a first aspect of the present invention, there is provided an electronic commerce system 
comprising: a series of point of sale terminals providing for point of sale information handling of a business: an 
intcrconneaion network interconnecting the point of sale terminals to a central database facility; a central database facility for 
storing information about each of the businesses for access by the operators of the point of sale terminals: and a scries of 
service providers interconnected to the central database facility for meeting requesu issued by tiie point of sale terminals. 

Preferably, the system also comprises a series of suppliers interconnected to the central database facility for meeting 
requests issued by the point of sale terminals. Iht suppliers can include at least one of: an import/export agent; a warehousing 
agent or a producer. The service providers can include one of: a third pany information vendor providing information upon 
requesL a financial transaction vendor providing financial transaction authorisation upon request: or an order fulfilment vendor 
providing order fulfilment upon request. The point of sale terminals can include local database information and programs which 
are preferably downloaded on demand from the central database facility. 

Access means for accessing the datastore as a member of the general public using a web browser and further means 
for communicating in a timely manner directly to the Point of Sale merchant and if that merchant can be there then 
communicating with the merchant in actual u'me. 

The requests are preferably iranniitted in the form of XML documents or die like to and from the central database 
facility. The request implemeniaiion siruciure can be preferably provided by a software development kit applicadons 
programming imertice. 
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The system can also include a scries of user mobile data entry devices which inicraa with the poini of sale icrminais 
in the authorization of a transaction. TTie mobile data entry device can include one of WAP enabled phones, mobile phones or 
bluetooih connected devices. 

Ideally, there is also provided a separate interaction unit such as a Web Browser for users to imcraci with the central 
database facility for the viewing of transaction statistics associated with the system. The viewing of transaction statistics 
preferably can Include utilising OLAP facilities on ihc central database. 

Actions undertaken by the database facility arc preferably in the form of workflow steps executed by the facility v«ih 
the workflow can be spawned by the template siruciure of the rcquca There can also be provided an interactive graphical 
database for interacting with the ccniraJ database facility. 

In fimhcr modified embodiments, inulriplc centralised database facilities are preferably peered and interact with one 
another to pertbrm functions. 
Brief description of the drawings 

Noiwiihsianding any other forms which may fall within the scope of the present invention, preferred forms of the 
invention will now be described by way of example only, with reference to the accompanying drawings in which: 

Fig. I illustrates schematically the arrangement of a first cmbodimcni; 

Bg. 2 illustrates the producuon of workflow in accordance with the first embodiment; 

Fig. 3 illusuatcs the process of execution of transactions by a merchant/consumer and 1 WN engine arrangement: 

Fig. 4 illustrates an alternative airangmcni of an embodiment of the invention; 

Hg. 5 illustrates the various structures in an embodiment of the invention 

Fie. 6 illustrates the carying out of transactions in accordance with an embodiment of the invention: and 

Fie. 7 tllustraics one software architectural structure of the IWN engine. 
Detailed description of the emk>odiments 

In the first embodiment, an interactive system is provided for carrying out business transactions over the Internet in a 
simplified and automatic manner. The transactions can include electronic ordering and distribution, web site generation and on 
going maintenance, proactive interaction such as faxing, e-mail and elecuonic funds transfer. Further, die system allows 
business clients to maintain their own database and allows dynamic access to accounting procedures and managemcm 
information systems including EFTPOS transactions. 

Turn to Fig. I. dicrc is illusiraied schematically the overall operational environment of a fiisi embodiment. The first 
embodiment I is denoted the IWN nciwork and includes various entities interconnected over an Iniemct environment 2. The 
elemcnis communicate with one another using XML messaging and CORBA (common object request broker). CORBA is a 
general purpose communication protocol that allows iranspaicm communications over a network. That means that the network 
is invisible to the development programmer in that they program as if the network is not there. 

The object oriented communications model is used for application interfaces within IWN engine private processes. 
For example, the IWN server clearinghouse 30 requests transaction authorisation from a Paymcm Engine 36 via a CORBA 
RPC (remote procedure call). The architecture allows distribution of objects over ihc network. Objects can be written in one 
language (say Java) and referenced using another (say c-h-). 
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A series of java applcis and scrvlcis on ihe web server provide references to objects on other servers through the 
CORBA communicauon inicnace. The local client enliiics e.g. 40 can be configured to ran Java applcis over an Intcmci 
browser lype environment such as that provided by Microsoft's Inicmci Explorer or Netscape's Netscape Navigator. 
AUemaiivcly. they may be a permanent Java application, iniegraiion into a third party point of sale or accounting package, or a 
currently hardware of software device. 

Each of a series of client side elements 4 1 - 44. 40. 34, 5 1 . 52 imeiact with an I WN engine clearinghouse 30 which 
operates as a clearinghouse for operations. The ncxibility of the arraneemeni allows for (here to be a client and server 
relationship in all cases (even when only one machine it is client and server on the same machine). The client has a reference to 
the server, but the chcnt knows no difference between the local reference and server, as CORBA encoding allows for the whole 
system to operate in a transparent manner. 

The IWN engine clearinghouse 30 ."serves as a XML and CORBA switchboard for the entire system. As noted 
previously, it consists of an message conversion engine 45. workflow repository 46. data/object store 48 and a transaction- 
processing engine 47. The Clearinghouse interacts wiih all external entities via open protocols such as XML and WML. and 
iniemal cniiiies via CORBA. CORBA provides a high performance, yet scalable and open infrastructure for IWN engine 
components to intcroperaie. Rather than a purely pcer-io-pccr or purely centralised communications model. IWN engine 
operates in a hybrid manner. The data/object store 48 can comprise a relational database and OLAPfOn line analytical 
processing) engine suitable for handling dynamic real-time E-commercc transactions and the OLAP of those transactions. 

The XML engine clearinghouse 30 provides a core clearinghouse application which interacts with a series of 
peripheral applications. These include a consumer front end ASP 31. a merchant terminal 32, a merchant partner web froniend 
33. an eCommerce brokerage type operation 34, general Internet access 35. a payment engine 36 and a messaging engine 38. 

The merchant terminal can comprise a point of sale (POS) terminal running via a browser 40 for operation by a 
merchant. This terminal can comprise java applcis for allowing the terminal to connect to the IWN network by means of a 
TCP/IP inicrconneciion. This component can be deployed to traditional POS developers as a "developers kit " which they can 
integrate lo a greater or lesser degree into their software, to enable their users to connect to the IWN network. The POS. 
terminal provides a facility for small lo medium sized businesses looking to establish an ecommerce presence. In its simplest 
form, the POS lermtnal offers a way lo clear plastic and cash transactions via the Internet, superseding traditional EFTPOS. 
However. NeiPOS also allows Enterprise Resource Planning fERP) point of sale, accounting, inventory managemcni and order 
fulfilment to browsers. PCs. NCs (Network Computers) and NC based cash register networks 41-44. 

Instead of utilizing point-to-point proprietary communication associated with EFTPOS, the system uses the ubiquity 
of the Internet to cany out transactions. Technically, the relevant API can be implen^enied as a Java or VB based software 
application that uses encrypted Internet communications to exchange XML RPC with XMLMarket application services, with, 
for example, the IWN engine clearinghouse 30. The consumer wcbfroni application service 31 automatically generates an 
Internet website presence for IWN engine or client's merchants using the information exchanged by devices on the IWN 
network. The website is a virtual representation of the business, autonomously reachable on the Imeroei. Consumers can use the 
website and make purchases without any kind of prior association with an IWN engine clearinghouse 30. Integration between 
the POS and website transactions via the IWN engine clearinghouse 30 creates a seamless order entry and fulfilmcm process. 

The merchant/partner webfroni application service provider 33 is provided to deliver the information to users of the 
IWN network through any (compliant) World Wide Web browser connected to the Inlcmet Apart from catering to the smallest 
enterprises, the merchant/panner webfront ASP provides mobility, deployability and rapid growth capability lo businesses of 
any size. 
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Both ihe consumer and nierchani/panner ASP are designed lo enable conversion of ihc data lo any format, so as lo 
enable il to be viewed on ANY device (ie mobile phone, web TV. PDA. kiosk cic) 

A brokerage facility 34 links websites together in a virtual communiiy. The system enables the products of all 
merchants in the communiiy to be queried in a consistent manner and provide for consumer driven queries which aggregate the 
data. For example the customer can specify the product and price desired and the database will query alt merchants lo ntttch the 
request. Consumers experience a shopping environment, consistent across all vendors within the IWN exchange system. 
Conversely, other eMails can present IWN engine generated information or web sites. 

Business to btssincss functionality enabled by IWN engine also allow merchants to collaborate for competitive 
advantage with their major suppliers. IWN engine eMail consumers enjoy an overlay or mcu-search engine capable of finding 
products by multiple criteria across multiple vendors. This is due to the faa that they are able to query not only the IWN engine 
held by Ihe local client, but also nodes from alt over the,woHd. 

User, connected by devices and in some cases specifically through browser sessions, arc typically only conneaed on 
a permanent or semi-permanent basis using low speed lines, whereas the clearing house can be full time connected with high 
bandwidth, redundant Inicmei links. Components like the POS devices 40 and brokerage services 34 task the IWN engine 30, 
which means they can leverage its permanent, high performance capability. The JWN server clearinghouse contains the 
business logic (described hereinafter) required to initiate and complete transactions, and can inicraa with any device which 
transmits standard message formats such as HTML. WML XML. IMAP etc and is connected to the Internet. It also frees the 
devices from the requirement to manage muhiple connections to multiple parties 

Funds transfer within the system is managed a Paymem Engine 36. One of the barriers to entry of the existing 
EFTPOS networks into eCbmmercc/lntemet markets is the proprietary nature of the protocols involved. Il is difficult to either 
effectively integrate these protocols with the more modem worldwide web paradigm into the SME environment, or for the 
existing financial institutions to develop an alternative to the Internet. XMLMarket merges XML and EDJFACT. (and other 
standards) by Troni ending' the various proprietary financial networks with an IWN engine. 

All IWN nclworic proccss-to-proccss communications can take place predominantly on lop of the TCP/IP protocol 
suite. The IWN network preferably conforms lo all relevant RFC and ( where applicable) ISO standards. 

JWN engine is designed to inieroperate with ihc widest variety of organisations possible. To this end. the extensible 
Markup Language. XML is often used to encapsulate all system-system transactions. XML provides a self-describing 
document paradigm: these documents are transmined via HTTP using the XML RPC (XML Remote Procedure Call) standard. 

Whenever sensitive or financial data is being transmined. IWN Engine HTTP application servers uses the Secure 
Sockets Layer (SSL) protocol to encrypt the data stream. SSL provides strong encryption to protect the data in transit. 
Panicipants in the market are pre^screened (to varying degrees depending on their user group) before admission, and 
authenticated using a non-proprietary protocol such as the RADIUS protocoi. Using RADIUS ensures a standards-compliant 
approach to pcrson-to-business authorisation, and transparently provides the option of using strong ciypiographic techniques 
like challenge-response or one-time password algorithms. 

In business-to-business iransaaions. X.509 cenificauon is used to authenticate auiomaied users transactions, which 
are also SSL encrypted. X.509 certificates are now available from a number of authoritative sources both internationally and 
domestically. IWN network centralised and distributed subsystems are protected behind industry standard ICSA 

The topology in which IWN network distributed subsystems arc deployed for a given region is dependent on demand, 
bandwidth availability and commercial agrcemcnis. From a purely technical perspective. Uierc can be a minimum of one and an 
arbitrarily unlimited number of each of these distributed processing units. Hiis provides for extremely large-scale deployments. 
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and retains ihc ability lo deploy in a locaJly cusiomiscd fashion where geographical, technical, commercial or political 
constraints apply. There are three major distributed subsystem orientations, namely oisiomer. vendor and service. 

The brokerage WebFroni 34 provides a mcia-laycr on top of arbitrary groups of IWN engine merchants. An IWN 
engine brokerage differentiates itself from other vfcb-mall offerings by: 

•Offering consumers a consistent shopping metaphor overlay, visually consistent across vendors. This Is achieved by 
overlaying a consumer shopping interface with communicates with any IWN engine compliant merchant. 

-Single transaction payment services across vendors. 

-Cross- vendor searching and comparison (at the vendors discretion). 

-The ability to integrate wfith and search other popular eMails in the event of an unsuccessful search. 
-An arbitrary number of eMails across an arbitrary number of vendors. 

The IWN engine shopping experience features a customer service window tailored for shopping. Services include gift 
tokens, lay-buys, recommendations, favourite merchants, and so on. The consumer interface travels with users regardless of the 
vendor entered. This consistency builds trust, and thereby consumer confidence. A variety of mall concepts is envisaged, with 
visual, audio and product placement scenarios tailored to target markets. 

Workflow operations 

The overall operation of the system can be as follows: 

1 . Transaction enters the system from a remote device. 

2. The network processes the request via its IP address and routes it towards the IWN system 

3. The IWN system identifies the request using either "tags" in the messaging format (messaging fonnats may include XML 
WML. HTML). IP address, or the pon on which the message was received. 

4. The IWN system then: 

la) Identifies workflow implicated by the transaction and begins to execute that workflow: 

(b) Converts the message imo a consistem IWN XML DTD to enable the workflow to execute. 

(c) Stores relevant information in the datasiore 

(d) Forwards messages to appropriate parties 

In many cases ' pcrsistem** processes may be frozen in the system to be fulfilled at a later date. 

The IWN engine clearinghouse 30 is directly connected to specific providers thai are able to fulfil order requests, 
third party information vendors able to provide information, and service providers that are able to cany out financial 
transactions such as credit card iransacdons or the like 36. Also interconnected to the IWN nelvwrk arc suppliers who receive 
requests for goods, import export agents, warehouse storage faciKlies and producers. TTiereby. the IWN Network is designed to 
handle logistics and inventory management as well as information about business relationships etc 

The data/object store is interrogated by at least five different sets of user groups (Using the OLAP interface), 
including web base users, point of sale (NETPOS) users 3-6. produa mediators 20-22 and product producers 23. consumers, 
and the client (telecommunications company or bank). When it is desired to query the database, an OLAP interface carries out a 
database uransaction. returning the results of the query. 



Substitute Sheet 
(Bale26)RO/AU 



WOOt/01300 



6 



PCT/AU0Oy0O73O 



In modified embodimcnis. ihe number of servers 30 can be rcplicaicd. IWN nciwork can then include a scries of 
servers and can be ihoughi of as a scries of nodes of differcm sizes. There may be one or several nciwork operations centres 
housing all (he applicaiions and a masicr data-store. There arc then the diem nodes, which are a local replication custonused to 
a demographic and/or political and/or geographical and/or legislative region. These users may be a retail point of sale system, 
or a larger corporate client. 

The global ponion (\t eiihcr the main network or a node situated at a •'client") is differentiated in thai all data can be 
collated and made available through the application server as single source for output in various forms such as HTML, as well 
as other relevant forms (XML CMI. WML VRML SHTML php. pwp. java objects, etc). 

The IWN network is regarded as distributed because clients have relcvam and alterable data nodes local to their 
machines. Hence relevant local and global database updating is required. The IWN network is dynamic because one local or 
global alteration might aeaie several internal network related opcraiions. The local server receives requests from its local user 
which will either be on the same machine or though ihe user's local network. The server will then either gci the information 
from lis local data .store or download it from the IWN server. The user is able lo simply request cenain information and Ihe 
server checks its cache if its there and returns it or otherwise downloads it from ihc application server (if available) and return 
and object representing the data. 

The local components arc only relevant to an individual user and/or user peer groups and is a subset of the larger 
client database s. Local ponions are regarded as local because the portion is local to the user's location. 

There is one major authoritative store of Information in each region in the serven data/object aorc. Non global 
information (like faxes etc) can be independently stored. The global portion has the largest subset of information which is of 
interest to customers of clients or client peer groups (for example: various on-line web shoppers). 

A smaller subset of IWN network information is relevant to a user peer group, and an even smaller subset is of 
imcrcst to a user. The global ponion of the IWN network is kept up to dale by periodically up loading local information (this is 
done when needed, for example: after local alteration). The NETPOS data can be implemented having write through capability, 
meaning that when a data update is requested by a NETPOS terminal the data will go straight to the main data source (if 
available) not just the cache. The global ponion of the IWN Network also processes information and passes it back to the client, 
in order to update their local database t again done when needed, for example: after customer alteration). Users access the IWN 
network using an interface which performs all tasks local to the user. The XML engine 46 runs the queries and return the results 
to the request source, either the web server or the POS server. 

The Following Automatic Functions can also be Provided 

(a) Web page aeation and on-going maintenance: 

The client is able to change a variable in their invemory management system locally. This in turn automatically 
updates the global portion of the IWN network, which automatically alters relevant web page elements. An example is a change 
of price on the local machine which is then reflected on the web site. 

(b) Ordering and order fulfilment: 

The IWN Nciwork has the functionality to allow point to point real time order fulfilmcni by facilitating catalogue 
maintenance (though the inventory system dynamically updating the price and the availability of the products) and offering 
direa connection to a third party order fulfilment client (such as FedEx). This includes the ability to set muluple relationships 
for each customer. For example supplier A may set different terms of payment and delivery for each customer. The user 
interface will communicate this order fulfilment criteria and will esublish and maintain relationships with each customer. Each 
user will also have the option of setting automatic re-order points. There re-order points can be set to trigger the dynamic and 
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cominual mainicnance of invemory levels in ihc cllcm's cmciprisc. The main aUvaniagc of ihis order fulfilmeni system will be 
its dynamic naiurc. for example: a customer queries ihc ccniral database and assuming availability of the product, results in Ihe 
order lodgement simulinneousty with the order fulfilment diem and the product client. The resuk will be a dynamic update of 
the level of inventory in the central database. 

(c) Accounting: 

By utilising the combination of inventory levels with supply side transactions (any transactions involving the 
movement of goods or services for a whole-sale price. i.e., between clients) and demand side transactions Iwith a customer) the 
IWN network has the capacity to provide summary information about the financial position of a client in real time. These 
reports will be displayed in a number of ways and in accordance with the accounting conventions of the geographical area. Il 
vknll focus pantcularly in profits by item type and by supplier (which is a client). 

fd) Customer information systems: 

By providing basic information about a customer and also about any on-line customers who purchase a show interest 
in products, the IWN network is able to give the various user groups (Merchants, clients, and consumers, etc) information about 
demographic factors of their customer base. Using OLAP technology enables unlimited number of views of the data, and 
resultant queries, li also allows them to track Ihe habits and preferences of consumers and uses intuitive search mechanisms of 
Ihc network to build personal relationships with the consumer. For example by tracking what a consumer has bought it may 
suggest other related items or similar items by the same supplier. The key aspect here is that the data can be viewed and 
modified by ihe user's customer representative. An application of this is the ability to transact with the on-line customer via 
chat and other communication means to give detailed information to the on-line customer. This is all done directly from the 
users local IWN network interface. 

(e) Management information systems (particularly inventory): 

TTic IWN network will enable a variety of management information queries to be parsed to the user. An advanuge is 
that the user is able to access information in real tinw and access information for the local database which has been entered 
globally. This includes order fulfilment information, information regarding the use and transactions on-line, and all this in 
combination with traditional point of sale data. 

From Ihe user's side, the difference is that the information, once entered in the local database, then periodically 
updates the global database without any proactive re-entering of information. 

The Proactive Furartions 

The following proactive functions can be provided: 

(a) Basic daily transactions and eiearonic funds transfer: 

While the transactions are all being entered in at the local (clients) level, they are also being periodically updated to 
the global database without being re-entered. This allows the information (local data) to have secure back-up. 

The establishment of a secure virtual private network (VPN) will then allow for the free two way transmission of data 
wherein the local client is able to be updated by the application server of the global database when queries are made to any 
panicular credit verification entity. 

Traditionally, funds u^sfer from the point of transaction (being a retail store, home-office, or back office etc) has 
been handled by a hardware device commonly called an EFTPOS terminal. Using a compliant point of transaction system, the 
user is able to clear a uransaction directly through their PC without additional hardware. For example, the attached appendix 
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seis out a point of sale devclopmcm tool-kit (SDK) called IWNcom which enables transmission of data from a traditional PC to 
the fWN network for clearance. The dau is described in a DTD and thus open to inclusion in a data-store. 

The IWN Client SDK (Software Development Kit) is designed to enable third party to Integrate their device or 
applications to take advantage of the IWN network functionality. These SDK's can be Java constructed and hence can 
readily be ported to the following devices: Windows 95. Windows 98. Linux. Windows 2000. Mac OS. PalmOS. WAP 
compaiible devices. Java Compatible devices. Smart Cards, and Java Cards. 

The fundament concept behind the SDK is that it initiates a common set of network level communications, 
security management, session management, and then transaaions over this secure session. Transactions may include (but 
not limited to): 

1 . Fmancial transactions, debit and credit 

2. eCommerce transaaions (purchasing of products, supply of products etc) 

3. Coment based informauon (such as audio and video .^iieaming etc) 

4. Bill presentment and payment 

5. Electronic ticketing 

6. OLAP and other reporting 

7. Service provisioning and management ( te aai vation of new services, termination of services) 

8. Smart card re-charging 

9. Device managemeni related transactions (such as fault reporting etc) 

Technically, the SDK has three layers: Communications. Network Security, and data transmission. The 
communicaitons layer will typically initiaie a network connection . detea status of that connection, and respond to various 
events relating the connection. The security layer will establish the validity of the user, establish the validity of the server .and 
then establish a secure connection between both parties. It may use SLL. DES. TLS. and other encryption and security 
processes and protocols. 

The Riosi complex layer is the data layer, which translates information about the client device, and actions on the 
client device . into a standard document (usually XML or WML documents) for transmission over the secure network. 
Informauon in this document may include information regarding a merchant, consumer, device, products, services, prices, 
geographical, loyalty. 

(b) • E-mail 31: 

The client is able to send/receive e-mail using the same interface they use for point of sale transactions arid all other 
group one or two function. 

(c) Fax 52: 

The client is able to send/receive faxes using the same terminal. These faxes are sent to the IWN network at which 
point they are distributed to the appropriate recipient. Incoming faxes enter the IWN network and arc filed using incoming CLI 
lecords. 

(d) Accounting: 
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The client is able lo input accounting infonnaiion and change the price of any resource be ii labour, siocic iicm or 
other and this information is periodically updated to the IWN network Once in the database it can be selectively used for 
designated areas of the clients web site. 

(e) Customer Relationship Management: 

The user (local NETPOS terminal user) is able to input customer details and these arc updated periodically to the 
global daubasc for later retrieval if necessary. TTie local database can draw a series of summary repons from the global 
database or selected information can be stored locally. Traditionally these queries arc referred to as CRM queries 

(0 Management information systemsfMIS): 

A user may lake the CRM information and organise it in such a manner as to enable business rules which arc 
particular to iheir organisation. In such a case they have faciUlaied a MIS system. 

(g) Order and order fulHlment: 

The abiliiy ro manually cnicr an order and then have ihat order updated to the global database to be later verified and 
placed and then confirmed or altemaiively confinned immediately. 

Vendors also uniquely gain synergistic connections with other IWN engine vendors. Through IWN engine, vendors 
can take advantage of shared warehousing and freight facilities, and economics of scale that they would otherwise not enjoy. 
Essentially a vendor can automate their production chain using IWN engine as the glue. This can be faciliuted in two ways: 

1 . The IWN engine connects to suppliers directly 

2. The IWN client uses established B2B infrastructure and relationships to connect to suppliers. An 
example is if a telecommunications company or Banking institution has a B2B system which communicated via 
EDI to a motor car company. IWN engine would simply connect to the in-house application rather than 
establishing a new connection to the car company. 

Although logically one jjubsysiem. the POS interface can be deployed in three distinct configurations. A NC Cash 
Register System 41. standalone NC/PC system 42. and Merchant/Fanner WcbFrom ASP 43. 

Essentially, the IWN server clearinghouse 30 can be unaware of client system topology and the decoupling provided 
by open standards ensures infinite possibilities for presentation/topology of POS systems into the future. The first two cases. 
NC Cash Register System 41 and Siatidalone NOPC System 42 can be identical technically, differing only in the number of 
processing units at a customer premises. Inventory, pricing and other operational data is stored locally. Transactions (in both 
directions) will initially be made using XML. and periodic reconciliation transactions can be performed to ensure convergent 
views of data at both the clearinghouse and dbtributed locations. 

In the case 40 where a Mercham/Pariner is connected using a web browser rather than a dedicated piece of hardware. 
POS view of is deployed as the Merchant/Partner WcbFrom ASP 33. The local data for this vendor can be stored within the 
Merchant/Partner WebFroni ASP 33: however this is completely transparent co both the user and the IWN server clearinghouse. 
The Merchant/Partner WebFront ASP 33 communicates with the IWN server clearinghouse 30 precisely as if it was an NC 
Cash Register System 41 or Standalone NC/PC system 42 utilising the attached SDK protocol. In all cases, the WcbFrom 
provides all required functionality to run the point of sale inventory, order fulfilment, debtors, and creditors functionality of a 
SME metchani/partner. Offline contingency capabilities can be provided in the case of dedicated hardware/software. 

In some embodiments, a merchant may already be committed to a particular application that cannot imeraa with 
XML. and therefore IWN network. Reasons for this can include: 
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' A closed, proprietary application forces duplicate data entry lo other entities. 

- The application vendor is not yet committed to XML for business-to-business integration. 

. Overwhelming market share by a vendor forces a de-facto standard. 

In order to overcome any reluctance to adopt the XMLMarlcei system. legacy applications 44 can be incorporated into 
the ovciail system by deploying a developers kit enabling third panics to develop IWN network extensions to their products, 
creating IWN network Extended Applications (lEAs). Such an arrangement assists in building a critical mass until XML (or 
subsequent standards) become a common feature of ERP software. 

In an tEA. the functions of the Vendor WebFmnt are be adapted to the legacy application. Inventory, pricing and 
other operational data can remain stored locally within the appUcaiion. Vendor Wcbfroni transactions (in both directions) are 
made in (at this stage) XML with the IWN server clearinghouse 30. and periodic reconciliation transactions are performed to 
ensure convergent views of data at both central and distributed locations. To the IWN server clearinghouse 30. the iEA behaves 
precisely as if it was an NC Cash Register System 41 or a Standalone NC/PC system 42. IWN network extensions arc simply 
used 10 eiiminaie redundant data entry, and to ensure synchronisation between the application and the. IWN server 
clearinghouse 30. 

The IWN Network Extended Application provides all the required functionality to synchronise the poim of sale, 
inventory, order and fulfilment functionality of a mcrchani/parxner. Offline contingency capabilities are not provided by IWN 
network: that is they must be provided natively by the legacy application itself. 

Payment Engine 36 

Cunent technology for funds transfer, transaaion clearing, micropaymcnt services and alternative electronic forms of 
cash often remain proprietary, non-standard, costly, and difficult to implement. Generally banks and credit providers insist on 
proprietary physical links with proprietary communications protocols and proprietary PCS terminals. Over the Internet, there is 
currently little improvement with the norm being proprietary technologies, uncertainty, lack of standards and rapid change. One 
of the major hurdles a small to medium sized enterprise (SME) faces in establishing a web-presence is the requirement to solve 
all of these problems and to re-implemcnt a financial transaction mechanism. Often. SMEs generally do not have the financial 
wherewithal to achieve this, resulting in a major barrier to eCommcrcc adoption. The IWN network solves this problem by 
abstracting the interface to multiple financial institutions and other payment transaction enablcrs via the Payment Engine 36. 
This subsystem provides a CORBA interface to the IWN scrva clearinghouse 30 through which all funds transfer, aedit 
authorisation, sales transaaions and merchant payments and reaipts can be processed. The Payment Engine 36 connects to the 
various financial organisations via the multiple proprietary mechanisms and point to point links, and is able to leverage higher 
bandwidth conneaions and better uansaction rates due to economies of scale. Financial transaaions arc simply another form of 
XML RPC. carried out using SSL encryption and authenticated with X.509 certificates and processed by the IWN server 
clearinghouse 30. Vendors enjoy significant benefits from this approach, including economies of scale, the ability to adapt to 
new technologies immediately, automatic inmsaction dissection and seulement across vendors: and of course. mo.5i importantly, 
simplification. Because the IWN Network paradigm is holistic, then this provides the ability to offer vendors differentiated 
pricing models for transaction clearance and participation. 

In the case where a "Client" has already owns a payment engine (such as the Nobil Gateway produced by Keycoip). 
the IWN engine can talk directly to the resident payment engine as apposed to the financial institutions. 

Messaging Engine 38 

Paitscipanis in any market require notification, confirmation, information and communication, between consumer and 
vendor, vendor and vendor, and consumer and consumer. Traditionally, this type of messaging was carried out by telephone 
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and posu and more recently by manual facsimile. However, the three criteria for effective messaging arc timeliness, authenticity 
and convenience. Telephony provides low auiheniicity and convenience tests, post provides low timeliness, and manual 
facsimile can provide low authenticity. 

"Die IWN Messaging Engine 38 provides the }WN server clearinghouse 30 (again through CORBA) with instant 
capability to generate a message request lo any number of panicipams. Initially. Email 51 and automated facsimile S2 may be 
provided. Over time. IWN network can introduce further services such as paging, voice synthesis and wireless notiFication 
services. All notifications can be serialised and time stamped, allowing a recipient to verify message authenticity as required. 
Email messages can be digitally signed where financial concerns exist. Finally, panicipants will be able to nominate preferred 
mechanisms for contact/noiincaiion. increasing the convenience level of the system. As a result, users will enjoy the 
convenience of integrated messaging from a single point. 

IWN server clearinghottse 30 

As noted previously, four major conceptual components forge the IWN server clearinghouse Application System. 
Architecturally, the glue between these components is primarily the Common Object Request Broker Architecture (CORBA). 
CORBA provides the flexibiiity required to implement a scalable solution at a single point: the IWN server clearinghouse may 
run on a minimum of one CPU. or may be distributed over multiple CPUs and multiple devices. If necessary, the IWN server 
clearinghouse can be a singular entity for a given IWN eXchange. and multiple Exchanges can seamlessly interact using XML 
RPC. The most immcdiaie consequence of this is that inter-markei e-iulfilment chains arc entirely possible. A worldwide chain 
of IWN exchanges serving country or continental regions can then be constructed, permitting global shopping with local 
supply. The clearinghouse elements include: 

DalA/Object store 48 

The foundation of the IWN server clearinghouse 30 is a large scale relational database management system with an 
object oriented paradigm overlay. Consumer and vendor information is stored safely and securely within the Data/Object store 

48. and is subject to inherent encryption and access control facilities. Database design can accommodate international, multi- 
lingual information, incorporate audit trails and implement two-phase commit technology ensuring reliability of transactions. 
Vendors, participating as merchants or partners can maintain their own local data stores. These can be bi-directionally 
spchroniscd via XML with the Data/Object store. Because the Data/Object store is relational. IWN network offers deeply 
flexible reporting and analysis opponunities to panicipants. 

XML Engine 46 

XML can be the primary messaging service used in the system. As such a component which addresses this component 
is pan of the architecture. As new standards de%'elop. this engine will be extended to include emerging standards. One of the 
primary benefits of XML is that it provides a common language for struauring documents that flow between business partners 
in a supply chain. Since XML documents share a common stiucture. the process of transforming documents into new data 
representations is vastly simplified. While XML offers far more flexibility and extensibility than either traditional messaging or 
EDI. XML by itself does not deliver the level of integration required to implement the IWN network. The XML Engine 46 
adapts other subsystems to communicate using XML and insulates them from the processes of encoding and decoding XML It 
provides the infrastructure to manage the integration process over time, securely and reliably route requests, and translate 
between messages that conform to different Document Type Definitions f DTDs). It also provides the facilities for 

• Integration of heterogeneous systems across firewalls. 

• Authorisation and security across corporate firewalls. 

• Plrovide guaranteed delivery of messages. 
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• Suppon for both documem and service based integration. 

• Change management and suppon for ongoing evoluuon. 

• Suppon for XML-based vocabularies and technologies. 
' Data transformation and mapping. 

- Scalability and performance issues. 
Workflow repository 45 

Workflow is concerned with providing the information required to support each step of the business cycle. The IWN 
network involves a mesh of information and transaction flows between market participants. In order to manage these (lows, the 
business rules for each iransaaion and participant t>'pc arc encoded and stored within the Workfiow Repository 45. a logical 
entity implemented on top of the daia/objcct store. It combines rules, which govern the tasks performed, and coordinates die 
transfer of the information required to suppon Uicse tasks Workflow Repository tasks may be physically moved over the 
network between participants or maintained in the IWN server clearinghou.sc with the appropriate processes given access to the 
data at the required times. Triggers arc implemented in the system to escalate exception conditions in the event of problems 
within the system. 

The operation of the workflow is depicted in Rg. 2. Data 60 sent to the IWN clearinghouse server, if not already 
in an XML format is forward to a translator 61 for translation into an XML format 62. The XML document is then queued 
45 in the workflow repository. The workflow repository bops through a process of requesting document objects 64. 
matching the document against possible types 65, determining what corresponding workflow should be undertaken for the 
documem type 66. The workflow is built 67 and added 68 to the workflow queue. Each added portion of workflow is Uicn 
process from the queue 69 and eventually a response returned 70. 

Hence, the workflow is spawned from the contents of each XML document. Once the documem has been revived 
and convened into a consistent data type, the engine processes the document based on actions relating to XML deflnilion 
in each document. 

The first objea that is requested is a "Profile" that matches the IWN exchange user with a profile. This profile is 
then matched with elements in the data and from this a workflow is spawned. TTiis workflow is comprised on a number of 
unique "actions" that together form a "graph" that define a particular route for each workflow. 

Tnmsaction processtng engine 47 

The IWN network employs a standard 3-iicr diem/server application model Server applications can be written as a 
set of interoperable, modular components using standard computer languages — such as C. C++, and Java. The Transaction 
Processing Engine then runs them in its scalable, high-perfonnance. secure, transactional environment. 

The Transaaion Processing Engine 47 logically sequences interaaions. using business niles from the Workflow 
Repository 45 to process transactions from the XML Engine 46. updating the Object/Data Store 47 along the way. ft ensures 
tha die business transaction i.i secure and reliable, and is completed with integrity. Some of the capabilities the Transaction 
Processing Engine brings to the FWN Network include: 

- Distributed Transaction Management - servers can participate in a distributed transaction that involves coordinated 
updating of multiple databases. The Transaction Processing Engine's uansaction management helps ensure that all databases are 
updated properly, or will rollback the databases to their original state, assuring that data integrity is maintained despite 
component faihires. 
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- Transaction Queuing " provides flexibiliiy in how and when transaciions should be processed or deferred. 

' Bveni Brokerage - allows for posting of system or application events ihai can be subscribed to by any authorized 
applicauon component in the system. 

From the above description and diem specifications, the following product functions may be identified: 

The IWN server clearinghouse handles ihc following transactions: Transaction verificaiion: Modify web-stofc 
information: Push / pull merchant website information: Modify inventory levels: Scrying of ASPs: Issue Mime. SSL: Queue 
messages: Prepare reports: Transmit payment receipt numbers: Send lay-buy information to Netpos: Transmit purchase rcqucsu 
loPOS. 

The IWN server clearinghouse deals with the following uansaction interactions with the Payment Engine: Credit card 
verification: Currency queries: Debit information. 

The IWN server clearinghouse processes information from the Consumer Wcb-Fronl ASP. This includes sorting of 
information: building the various websites and payment methods 

The IWN server clearinghouse assists in the operation of the E- Brokerage ASP in addition to the Consumer ASP in 
the following manner Provides an access point for a customer: Run iniclligeni queries: Store customer preferences: Allow 
dispute resolution: Payment methods 

The IWN server clearinghouse also allows third-pany data interpretation 
t Logistics companies interactions. 

• Integrate other multinational companies. 

• Integrate other e-commerce programs. 

• Integrate ERP. SAP 

The IWN server clearinghouse must be able to handle: 

• Produa information 

• Merchant infonnation 

• Supplier / mediator / customer Information 

• Limited website information 

• Financial (goods) information 

• Transactions >. /) 

• Rcceipcs 

• Tax 

• Payment method selection 

• Lay-buy infonnation 

• Show customer infonnation 

• Show shipping information 

• Quotes 
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• Terms of sale 

• Price specials, promoiions 

• Dispute reason codes 

• E-mail: Send, receive, history 

• Business repons: Sales (per period) customer, supplier, product, employee, inventory, delivery, profii. 

• Accouniing information: Accounts receivable, payable, total labour costs, cost of goods sold, etc. 

• Faxes 

• Web page infomiaiion: (Wizard setup. Product caiegorisaiion. Webpage administration. Statistics) 

The following describes the users interacting within the system. 
Consumers 

A consumer is simply defined as a person or pany that initiates a transaaion with a vendor or multiple vendors within 
IWN network. Imemci consumers use an brokerage or a merchant site created by the IWN Wcbfroni ASP 31 as a user interface 
through which transactions are performed. Of course, consumers can also initiate transactions physically ai the customer 
premises. Customers arc also able to spawn their own personal IWN customer interface which is customised lo their needs and 
allows them to conduct specified OLAP queries of the database (see diagram ji - pcier ask me for the customer details screen) 

Merchants 

Individuals or organisations that offer products or services for sale to consumers arc defined as Merchants within the 
IWN neiworic framework. They participate in uansactions using a spectrum of equipment, from sophisticated proprietary 
software with XML capabilities through to a simple web browser. All transactions, whether cash or plastic, arc rccoided and 
tracked on behalf of die Merchant by an instance of the IWN engine diereby allow managemem information reporting 

Mediators 

A mediator is a merchant that sells lo other menrhanis. They may offer .semi-finished goods or components 
(traditional supplier lolc). or services thai conqjiemcnl or facilitate the pnKJuciion process. A freight company, insurance agent, 
graphic dcsigna. vegetable wholesaler or coffee bean supplier may be considered an IWN cXchangc product mediator. 
Common mediators include distribution, warehousing and import/expon agents. 

Enablers 

Financial institutions, credit providers, cyber-cash agendcs. micro-payment vendors, iclccommunicauons caniers. 
software and web design companies arc all enablers widiin IWN network. An cnabler provides services to consumers. 
mcn:hanis. and mediators by facilitating transactions as opposed to supplying the goods and services thai comprise dicm. 

Otfier Markets 

The IWN network is based on Uic open, scalable, busineswo-busincss standards such as XML Because of this, die 
IWN network can communicate witfi any other maricei or party that also adopts open standards. For example. Microsoft is 
pn)moiing a technology called -BizTalk". whidi consists of a set of XML DTDs for business- to-business transactions. IWN 
nawork is automatically compaubic with BizTalk as a result. 
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Clearing House Functional requirements 

The following tables sei out in more dciail the implementation of the functional requirements of the overall IWN 
server clearinghouse system. 



Operation 


Transaction venTication 


Inputs 


• Transmitting purchase request 


Processes 


• Any purchase or reium of item will be logged in the system cither by a user input or 
automated logical process 

• Verification of user. 

« Verification of the amount being sent. 

• Identification of the debtor and creditor 

• Alert to the payment engine to transfer funds from purchaser to vendor 


Outputs 


• Alen / confirmation to die user of the vansacdon 

• Logistics / delivery information 

• Transaction / order number 

• Suggestive sale infomtation 




Operation 


Modify web-store information (From PCS) 


Inputs 


• Product descriptions. 

• Product Id's. 

> Produa pricing information. 

• Product availability. 

• Produa preference and placement on web page and in terms of search queries and 
results 

• Modify merchant informauon center 

• Modify credit card acceptance 

• Modify store status (open/closed/coming soon) 

• Unique product placement circumstances such (ie Gift opponunities) 

• Product logisuc information. 

• Product compatibility information (product inclusive and exclusive rules). 


Processes 


• On upload of product information into die database, and after verification 
acceptance, the above information is stored in the database 
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Outputs 


• Confirmation of product catalogue entry. 

• Acceptance of produa into system 




Operation 


Push / pu)] merchant website informadon 


Inputs 


Upon request of a URL by a user or need for additional information by the clearing house to 
parse to the web from 


Processes 


• Usa request of URL establishes call for web front information 

• If customer has estabHshed profile, log of information 

• Regardless of customer profile, fog of all URL usage information 

• Based on customer profile, query currency, language and other demographically 
specific deliverable's 

• Query of relevant merchant informaiiun for changes at NetPOS level 


Outputs 


Presentation of URL along with information builds web from and marketing information. The 
web front is displayed in die relevant dialect and currency for the user 




Operation 


Modify inventory levels 


Inputs 


• Inventory information 

• Availability information 

• Stock level information 

• Deliverabiliiy information 

• Backorder fulfilment information 


Processes 


• Transaaion at POS or Web Front sends produa update to clearing house. 

• Clearing house checks for stock availabi lity and for the validity of transaction 

• Transacdon is appioved or rollback occurs 


Outputs 


• updated inventory levels 



Operation 


SenringofASPS 


Inputs 


Request for an application by user at an agreed fee and duration 


Processes 


User requests application through any compliant device 
Clearing house queried for avathd>iKiy 
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IWN server clearinghouse evaluates bandwidth availability 
Time stamp establishes the start time of use 
Fee is added to user account 


Ouipuis 


Applicaiion delivered for use and session spawned for prc-agrccd period 
User is charged 



Operation 


Issue Mime, SSL 


Inputs 


Secure session requested by user 


Outputs 


Secure session is spawned for user 



Operation 


Queue messages 


Inputs 


Any transaction requested from the IWN server clearinghouse 


Processes 


User makes request for URL. application, information, or intuitive response from the IWN 
server clearinghouse 


Outputs 


Response of success or failure tVom the server 




Operation 


Prepare reports 


Inputs 


User requests information from the server pertaining specifically to statistical or aggregated 


Processes 


User authenticated 

User privileges established with regards to the requested information. 
Success or faihire for request 
Report generated from relevant data 


Outputs 


Report delivered to web front or Ncipos 
Upon faihire rollback 




Operation 


interface with tUrd party vendors 


Inputs 


Request from third party vendors for information 
Request for information from third pany vendois 


loesses 


Third party sends query to IWN server clearinghouse via either dedicated line or TCP/IP 
request 

Query workflow repository for data type recognition 
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If data type recognised, convened to standard DTD 
User allocated access privileges 

Request for infonnaiion processed and checked against access rights 
Submission of information processed and stored 
Penisiem object created if request for later fulfiilment 
Request to vendor fulfilled 


Ouipuu 


information from vendor fulfilled/rejected 
Request from vendor fulfilled/rejected 
Request to vendor fulfilled/rejecied 




Operation 


Send lay-buy information to Nelpos 


Inputs 


Entry of credit card information. 

Debtor information and verification (credit card user) 

Debtor contact information 

Product information. 

Pricing information. 

Product availabilily and promoiion information. 


Processes 


Creation of a lay-buy account. 

Linking of current to previous lay-buy accounts. 

Seuing of lay-buy time periods 


Outputs 


Lay-buy confirmation information 
Transmittal of lay-buy status 
Transmiiial of lay-buy costs and expenses 




Operation 


Transmit purchase requests to Netpos 


Inputs 


hem purchased 
Debtor information 
Payment method 
Credit card details 

Logistic information (delivery schedules and methods) 


Processes 


Customer purchases item from any device 
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Request sent to clearing house 

Replication of data at clearing-house and NeiPOS 


Outputs 


Conflnnaiion of purchase 
Receipt number 
Delivery details 



Operation 


Verify credil card information 


Inputs 


• User details 

» Credit card details 

• Purchase details 

• Transaction confirmation details 

• Receipt number 


Processes 


• Credit card information stored in clearing house 

• User authorised at log-in 

• Purchase request processed against inventory levels 

• Transaction sent to acquiring bank for verification 

• If successful changes to inventory levels 

• If fail then rollback transaction 


Outputs 


• Verification of credit card details 




Operation: 


Transmiltal of payment receipt numbers 


Inputs 


• Accoum / transaction number 

• Amount of transaction 

• Method of payment 

• Date of paymem 

• Payer information (user) 


Processes 


• Update of user account information. 


Outputs 


• Transaction amounts due 

• Receipt number 
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Operation: 


Currency conversion 


Inpucs 


• Merchant currency preference 

• User currency preference 

• Current currency information 


Outputs 


All users view currency that they have previously selected 



Operation 


Administration reports 


Inputs 


Informaiion stored by the server will be used to determine the number of users. 


Processes 


As pan of the rcpon generation process - the number of users that have contributed information 
will be determined from information stored on the server. 


Outputs 


The number of users who contributed will be placed at the top of the summary report for 
adminisiraiion purposes 



User Interfaces 

Apan from the usual browser interfaces, the PCS interface for can be a point of sale hardware device such as the 
5 Comm2000 device from Keycorp. The configuration at point of sale may include a cash register, customised keyboard and 
odier typical point of sale devices. 

As IWN network is based on a client/server computing environment, the necessary hardware device required to access 
the network is a Internet connection to connea to the IWN server clearinghouse server. This can be implemented through a 
third pany ISP. 

10 Software Interfaces 

The software to be interfaced with the fWN network can be a Java client running on a Web browser (Netscape 
Navigator 3.x. Netscape Communicator 4,x. Internet Explorer 3.x). Altcmalivcly. the operating system (Windows 9x, 
Windows NT. Unix. MacOS) can interact direaly using the TCP/IP protocol. 

As described above, any third pany can interact with the system by integrating to it using the IWNCom's 
I S development kit as shown in the anached appendix A. 

(c) Commum'cations Interfaces 

The data communication protocol required to use the IWN Network can be the standard TCP/IP protocol. The type 
and speed of connections to the Inteniet will be varied amongst the different users and docs not impaa the design of the system. 

POSio XML 

20 The POS device provides a direct translation into XML Initially, the POS device opens a TCP/IP connection with Ute 

IWN server. The credit or debit card data is then sent to the server. The process firstly involves the negotiation of conneaion 
and session's with the IWN engine. The process involved is slightly different for Credit and Debit. For a credit card, the steps 
inchide: 
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1 . Merchant prompted to swipe card either by the third pany software (such as Quicken or M YOB) or by the IWN client 
side component directly 

2. Merchant swipes card 

3. Card details sent back to the PC (instead of itmaining in the EFTPOS device) 

4. Either infonnaiion gathered by the third pany software and passed to the IWN objea or gathered by the object 
directly 

5. IWN Client side Component (either Java based or ActiveX) collects the credit information convcns it to AS2805 
compliant XML data, and sends it to the server. The collection of information can also include (not limited to) 
product informaiTon . merchant information, and information about the terminal. The produa information is 
extrapolated from a local daia store using either supplied APIs or via customised integration. Alternatively the 
product information can be sent as a batch Hie at pre-deiermined intervals. 

6. The server sends a response back to the client side component which leads to receipt printing and other related retail 
business requirements. 

Debit solution from POS 

The debit solution may include more iradiiional pin key encryption devices (such as the Com2(X)0 device from 
Keycorp). or newer technologies such as WAP and Bluetooth. Using the more traditional POS hardware configuration, the 
system can operate by the following steps: 

(a) Merchant prompted to swipe card either by third party software (such as MYOB or (Quicken) or by the IWN client side 
component: 

(b) Merchant swipes card:. 

(c) A ECR message sent to the EFTPOS Hardware (Which is capable of Key PIN Encryption), (d) The PIN Pad or like device 
prompts the user to enter a PIN number (usually four digits). The user enters the PIN number 

(e) The PIN number is encrypted with 3DES encryption and set back to the computer via an ECR Message. The message is 
either received by ihc third pany application or the IWN client side component. The 3DES encrypted message is then sent to 
the IWN server along with other XML information regarding the transaction including (but not limited to) Product, customer, 
merchant, and terminal information. 

(0 The IWN Server passes the PIN to the Acquiring institution (potentially via an internal gateway first) and then through to 
the issuing bank, (he issuing bank then returns a response as to the funds available. 

An alternative method can comprise the following steps: 

1. Mercant Swipes card in POS terminal 

2. POS encrypts the data (DES usually) and sends it back to the PC 

3. Only the AS280S (or similar financial information) is sent to either 

(a) The IWN engine which then forwards it to a financial instiiutioQ 

(b) Directly to the fuianctal gateway 

4. Then when the message is confirmed and sent back to the server a new XML document is spawned that sends the 
transactions details to the IWN server (over the same link) 
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li is also importani lo identify ihai infonnauon is only stored in the IWN senw once ihc iransadion has been 
approved (besides faull logging and invalid transaction logs). 

The debit transaction can be extended to other arrangements which utilise non traditional Point of Sale Hardware. For example, 
debit card iransaaions can be conducted over a mobile phone interface using a WAP enabled phone having Key PIN 
encryption. The process, as illusiratcd in Fig. 3 can proceed as follows: 

1 . Sale transaction agreed upon between Merchant/Retailer 71 and customer 72: 

2. Merchant selects debit card on their POS device 73: 

3. Merchant enters mobile phone number or initiate SMS message on the POS device: 

4. Message sent to WAP or SMS server 74: 
3. Message sent to IWN Engine 7S: 

6. Message forwarded to mobile phone 77 via WAP Gateway 74: 

7. PIN entered on mobile phone and encrypted and sent to IWN engine 75: 

8. IWN Engine sends encrypted PIN to Acquirer Gateway 78 and Sends Merchant ID lo the IWN Engine: 

9. IWN Engine waits for response: 

10. Acquirer 78 forwards the PIN to the card issuer 79; 

1 1 . PIN authenticated by the Issuer 79: 

12. Response sent to IWN Engine 75; 

13. Response forwarded to merchant point of sale 73; 

14. Sale completed or denied. 

Alternatively, the system can operate to inchide consumer initiated transactions over WAP. This can comprise the 

steps of: 

1. Sale completed 

2. Merchant selects Debit via WAP/SMS option 

3. Consumer Selects Debit via WAP/SMS 

4. Consumer enters Merchant ID via WAP interface of mobile 77: 

5. Consumer enters PIN via WAP interface: 

6. Consumer sends message with PIN (Key Pin encrypted) to the IWN Engine 75: 

7. IWN Engine sends encrypted PIN to Acquirer Gateway 78 and Sends Merchant ID to the IWN Engine 

8. IWN Engine waits for response 

9. Acquirer forwards the PIN to the issuer 79; 

10. PIN authenticated by the Issuer 79; 
U. Response sent to IWN Engine 75 

IX Response forwarded to merchant point of sa]e73 
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1 3. Sale completed or denied 

Aliemaiively. the system can operate to include merchant and consumer initiated transactions a Bluetooth network. 
For example, where the merchant has a blue tooth interface and the user has a Bluetooth enabled phone with a Key PIN 
encryption device, the process for executing a sale can comprise: 

1. Sale completed 

2. Merchani selects Debit via Bluetooth option 

3. Merchant swipes card 

4. Card and Merchant details sent via Bluetooth to the phone 

5. Consumer enters PIN 

6. Consumer sends message with PIN (Key Pin encrypted) to the WAP Gateway 

7. WAP Gateway sends PIN & card number to IWN Engine 

8. IWN Engine sends encrypted PIN to Acquirer Gateway and Sends Merchant ID to the IWN Engine 

9. IWN Engine waits for response 

1 0. Acquirer forwards the PIN to the issuer 

11. PIN authenticated by the Issuer 

12. Response sent to IWN Engine 

1 3. Response forwarded to merchant poira of sale 

14. Sale completed or denied 

Further, where the consumer wishes to initiate a Bluetooth transaction, the transaction can be as follows: 

1. Sale completed 

2. Merchant selects Debit via Bhietooth option 

3. Consumer enters PIN into mobile 

4. PIN encrypted in SIM card 

5. Card details sent via Bluetooth to the POS device 

6. Meichant swipes card 

7. POS device sends PIN & card details to IWN server 

8. IWN Engine sends encrypted PIN to Acquirer Gateway and Sends Merchant ID to the IWN Engine 

9. IWN Engine waits for response 

1 0. Acquirer forwards (he PI N to the issuer 

11. PIN authenticated by the Issue 

12. Response sent to IWN Engine . 

13. Response forwarded to merchani point of sale 
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1 4. Sale completed or denied 

Graphical User Inrerface fGU!) to ihe IWN Clearinghouse engine 

As each cransaciion can be stored in ihe data/objeci store, a complete overview of each independent IWN Engine 
system can be made available from a GUI administraUon window. The views provided preferably include: 

1. Service activation 

2. Service Provisioning 

3. Work-flow manipulaiion 

4. Logical network overviews 

5. View of all **actions" available in ihe system 

6. View and manipulation of work-flow "graphs** representing the logical order of actions in forming any one work-flow 

7. View of devices on the network and the role that they play in the network overall 

8. Activation of new devices 

9. Activation of new clients and related business requirements 

10. Activation of new client types (such as an SME Grouping) 

1 1 . View of logs for each client, device, service 

12. Mapping of new datatypes 

13. .Mapping of existing datatypes to new services or devices 

14. Automated audit trails 

1 5. Activation of peering to other engines 

OLAP Processing 

The data in the data/object store repository can be queried using OLAP techniques (online analytical processing), 
ROLAP (Relational Online Analytical Processing). MOLAP (Multi-dimensional on-line analytical processing) . and other 
similar techniques. OLAP (online analytical processing) enables a user to easily and selectively extract and view data from 
different points-of-view. Hence, this provides an extremely flexible query tool that enables multi-dimensiona) queries. OLAP 
uses a multi -dimensional data base where each data element is stored as a highly disaete piece of information. OLAP can find 
the intersection of two to "n** relationships between the data. 

The IWN architecture uses the following techniques to extract information from the daia*store: 

1. Any device or access point either compatible with or understood by the IWN engine (in terms of data and network 
compatibility) sends a query to the associated server (ie WAP server. HTTP server) or conneas directly to die IWN 
engine. 

2. The message format is convened to the appropriate data type for the IWN engine 

3. The message is recognised by the Engine as an OLAP query 
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4. This spawns a conneciion lo the IWN Scrvlei Engine which launches a servlci lo mange ihc query 

5. The scrvlei ihcn sends all queries lo the Workllow Repository Manager that protects the IWN daia-siorcs from 
external tampering 

6- The Workflow Repository Manager connects lo the data base and returns all relevant information to the Servlci 

7. The Scrvlct then returns the response to the Engine and the transaction is pioccsscd and sent back to the appropriate 



device 



The OLAP aichiieciurc is novel in ihai ii deals with ubiquitous devices and multiple queries from any of, but not 
limited to. the following: Web Browsers. WAP Devices. WebTV Devices, Java enabled devices (Ic that can run a JVM). 
Kiosks. ATM s (Automated Teller Machines). The OLAP archiicaure can be designed to accept queries from any device 
(Sending valid requests) and return response lo that said device (using valid responses). 

feering muhi-instances of the engine 

Distributing various instances of the engine allows each engine to link together and appear lo be one engine under 
particular rircumstanccs. This enables two owners of the engine to enter into commercial agreements lo comribuie diem 
collateral lo increase the momentum of their commercial endeavours. For example, if company A has I CO merchants using their 
engine and company B has 100 mcichanis. they are able to peer ihcir engines to enable any consumer seeking merchants to 
query all 200 merchants. 

This process can be enabled via a secure socket connection between the engines and the ability for a OLAP query on 
one engine to access a business rule to queo' another enginc/s and the IP address of the other engine/s. Much like a search 
engine, the Servlet technology then opens a session with the foreign engine and awaits the complete query of all local and 
foreign engines before reluming ihe response to the user. 

Obviously various modified embodiments and alternative representations are possible. For example, in Fig. 4 there is 
illustrated an alternative representation of an embodiment of the present invemion. Various inieraaivc devices, for example 
shop front point of sale terminals 80. Internet device 81. WAP devices 82. Kiosk terminals 83. PDAs 84 and Web TV devices 
85 are each equipped with an Sdk to convert transactions into an XML document in accordance with associated document type 
definitions. -Pie XML documents arc scm to the XML engine 86 for action and storage. The XML engine in turn provides a 
series of modules for interaction with the data store. These include an OLAP module 87. logistics module 88. client billing 
system 89, loyally modules 90 and brokerage portal 91 and bank clearing house 91. Further, in various embodimcms. the IWN 
engine 86 can be paired with other engines 94 and undertake other transactions with legacy applications and other iniemci 
system 95. Fig. 5 illustrates an alternative archiicciual arrangement and Fig. 6 illustrates the processing of a transaction in 
aaordancc with the afonrrocmioncd principles, with Fig. 7 illustrating an allcmaiive view of the architecture of ihe IWN 
Engine, 

It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to 
the present invention as shown in the specific embodiments without departing from ihc spirit or scope of the invemion as 
bn>adly described. The present embodiments are. therefore to be considered in all respects to be illustrative and not resiriciivc. 
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Appendix A 

Login DTP 

<!DOCTYPE HTML PUBLIC •-//W3C//DTD HTML 4.0 Transitional/ /EN" > 

saved from url= ( 0063 }http: //dev. indwide. nee/milestones /milescone- 
4/xinl/dtd/login.dtd 
<HTML><HEAD> 

<META content="text/html; charsec=windows-1252" hctp-equiv=Coatent-Type> 
<META content=''MSHTML 5.00.2919.6307- name=GENERATOR></HEAD> 
<SODY><XMP><! — 

IWN Login DTD 

Version: $Id: login. dCd.v 1.4 2000/06/05 03:04:46 dth Exp S 
Milestone: 4 

--> 



<! ENTITY % iwn.elemencs 
<!ENTITY % login^elements 
<! ENTITY % req[uest_elements 
<! ENTITY % response^elements 
options? "> 

<! ENTITY % authentication^elements 
< '.ENTITY % options_elements 



• login ■> 
•(request j response) "> 
"authen-ication*> 

•authentication?, code, description. 

"(id, password?) | dsa"> 
'workf iow+"> 



< 'ELEMENT iwn (%iwn_eleinents; ) > 

<!ATTLIST iwn version CDATA #REQUIRZD> 

<JATTLIST iwn session CDATA #IMPLIED> 



<!ELEMENT login (%login_eleinents; ) > 

< ! ELEMENT response ( %response_elements ; ) > 
< ! ELEMENT reques t ( %request.elefflents ; ) > 

<!ELEMENT authentication (%authentication_elements,- )> 
<!ATTLIST authentication type CDATA #REQUIRED> 
<!ATTLIST authentication algorithm CDATA #IMPLIED> 
<! ELEMENT id («PCDATA)> 
<!ATTLIST id type CDATA IIMPL1ED> 



<• ELEMENT password f#PCDATA)> 

<> ELEMENT dsa (# PCDATA )> 

<! ELEMENT code (»PCDATA)> 

<!ATTLIST code type CDATA IREQUIREO 

< 'ELEMENT description («PCDATA)> 

<! ELEMENT options (%opticns_elements? )> 

< (ELEMENT workflow (#PCDATA)> 

<!ATTLIST workflow id CDATA «REQUIRED> 



< /XMPx /BODYx /HTML> 



IML Login Request 

<?xral versions' 1.0* ?> 

<!DCXrrYPE iwn (View Source for full doctype. , .)> 
<! — Comment — > 
<iwn version=*0.4*> 
<iogin> 
<request> 
<»-- 

IWN Users can login either by their email address 
or their IWNUserlD. 
example: 

<id type='email">foo@bar.com</email> 

<pas sword> f oo< /password> 

or 

<id>959818</id> 
<password> f oo< /password> 
--> 

<authentication type=i'iwnuser"> 
<id types -email '>bottlef astStelstra . com</ xd> 
<password>roerchant< /password> 
< / au thenticat ion> 
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</request> 

</login> 

</iwn> 

XML Login ReeponBe 
<?xnil versions "l.O* ?> 
<!DOCTyPE iwn > 
<! — comments — > 

<iwn version='0.4- session=-6d518aa77a49dBbc823037111dd877d6931d6245-> 

<login> 

<respon5e> 

<code type=* login ">0</code> 
<descripcion>Login Successful < /descr iption> 
<! — 

These are the workflows that the user is allowed to execute. 
In this case, the user can now 

- Request a Purchase ID 

- Request a Transaction Status 

- Logout 

— > 

<options> 
<workf low id= ' 2 " >Logout< /workf low> 
<workflow id='3'>Purchase ID< / workf low> 
<workflow id='7'>Transaccion Status < /workf low> 
</options> 
</response> 
</login> 
</iwn> 
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Purchase DTD 

<!DOCTyPE HTML PUBLIC --//W3C//DTD HTML 4.0 Transitional/ /EN •> 
<! — saved from url= (0066lhtcp: //dev.indwide.neC/milestones/milesco^e- 
4/xmi/dtd/purchase.dt:d — > 
<HTML><HEAD> 

<META contenc=" text /html; charsetswindows'1252* http-equiv=Content-Type> 
cMErTA content=-HSKTML 5.00,2919.6307- name^GENERATORx /HEAD> 
<BODY><XMP><! — 

IWN Purchase DTD 

Version: $Id: purchase. dtd.v 1.4 2000/06/05 03:04:46 dth Exp $ 
Milestone: 4 - 

— > 

<!-- 'eiwn> children — > 

<! ENTITY % iwn^elements •purchase* > 

<!-- <purchase> contains either <request> or <response> --> 
< 'ENTITY % purchase.elements 'request I response"> 

<!-- <request type="..'> — > 

<! ENTITY % request_types 'purchase | purchaseid | purchasereversal | 

purchaseauthorize*> 

<}-- <request type= "purchase" > children — > 

<!ENTITY % purchaserequesc_elements ■source, delivery, payment, products?, cosf> 

<!-- <req[uest type= 'purchasereversal '> children — > 
<i£NTITy % purchasereversal_elemencs "purchaseid'> 

<!-- NOTE: purchaseid and purchaseauthorize have no children other than 
<authentication> 

<! — 50 they are not specified here, as <auchentication> is a required element 

— > 

<•-- <authentication> children — > 

<!— NOTE: digital signatures/hashes would be added here — > 
<!ENTITY % authenticacion.elements '(id» password?) | dsa*> 

<\ — <response> children — > 

<!ENTITY % response.elements 'authentication? , code, description, rrn?. 

options? •> 

<! — <options> children — > 

<! ENTITY % options.elements 'workflow* •> 

<! — <payment> children — > 

<! ENTITY % payment_elements "card | iwnuser'> 

<source> children — > 
<! ENTITY % source_elements 'pos | web*> 

<! — <delivery> children — > 

<! ENTITY % delivery_elements 'address | pos"> 

<•-- <card> children — > 

<! ENTITY « card_elements 'name?, number, expiry, account •> 

<! — <products> children --> 

<! ENTITY % products.elements 'product* '> 

< 'ENTITY % pos_elements 'terminalid'> 

<!-- <source/pos> children — > 

<! ENTITY % web.elements 'client, server' > 

<! — <delivery/address> children — > 

<!ENTITY % address_elemencs "level?, number, street, suburb, city, state, 

country, postcode' > 

<* — <products/product> children — > 

<!ENTITY % product.elements 'productid, name?, description?, unit, 

quantity. cost*'> 
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<!-- <products /produce /quant icy> children — > 
<!ENTITY % quancity_elements 'cosc*'> 

<! ELEMENT iwn (%iwn_ele]nents; )> 

<!AmiST iwn version CDATA #REQUIRED> 

<!ATTLIST iwn session CDATA «IMPLIED> 



< ! ELQfENT purchase { %purchase_elements ; I > 
<!ATTLIST purchase id CDATA »IMPHED> 
<!ATTLIST purchase authorize CDATA #IMPLIED> 



<!-- <requesc> elements — > 

<!— <req[uesc> muse contain <auchentication>, and either purchase reversal children 
or purchase request children — > 

<1ELEMENT request Authentication, ( (%purchasereversal_elements; ) | 
<%purchaserequest_elements; ) ) ?) > 

<!ATTLIST request type < %request_ types ; ) »REQDIRED> 



<!-- <request/authentication> elements --> 

<! ELEMENT authentication {%authentication_elements ; ) > 

<!ATTLIST authentication type CDATA tREQUIRED> 

<!ATTLIST authentication algorithm CDATA »IMPLIED> 

<! ELEMENT id (iPCDATA)> 

<!ATTLIST id type CDATA «IMPLIED> 

<!ELEMENT email («PCDATA)> 
<! ELEMENT password (« PCDATA )> 
<! ELEMENT dsa (8 PCDATA )> 

<!" <request/purchaseid> elements — > 
<! ELEMENT purchaseid («PCDATA)> 

<!— <reque5t/source> elements 

< ! ELEMENT source ( %source_elements ; ) > 

<!-- <request/source/pos> elements — > 

< * ELEMENT pos ( %pos_el ements ; ) > 
<! ELEMENT terminal id («PCDATA)> 

<!— < request/ source /web> elements --> 
<! ELEMENT web (%web_elemencsM> 
<! ELEMENT client («PCDATA)> 
<! ELEMENT server (I PCDATA )> 

<!-- <request/delivery> elements — > 

< * ELEMENT del ivery ( %del ivery.elements ; ) > 

<! — <requesc /deli very /address> elsnents — > 

<!ELEMENT address (%address.elements; )> 

<! ELEMENT Street («PCDATA)> 

<! ELEMENT suburb (IPCDATA)> 

< 'ELEMENT city (#PCDATA)> 

<!ELEMENT state (#PCDATA)> 

< 'ELEMENT country (#PCDATA)> 

<! ELEMENT postcode (ff PCDATA )> 

<! — <request /del ivery /pos> elements — > 
<i— < {ELEMENT pos («PCDATA)> — > 

<! — <request/payment> elements 

< I ELEMENT payment ( %payment_elements ; ) > 

<!-- <request /payment /card> elements 

<! ELEMENT card < %card_elements ; ) > 

<! ELEMENT name (# PCDATA) > 

<! ELEMENT number («PCDATA)> 

<! ELEMENT expiry (# PCDATA )> 

<!ATTLIST expiry month CDATA #REQUIRED> 

<!ATTLIST expiry year CDATA »REQUIRED> 

<!EL£HENT account (#PCnATA)> 

<! — <request/products> elements — > 
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<! ELEMENT produces (%producCS_el&nents; )> 

<!-- <requesc /produces /product> elements — > 
< I ELEMENT product ( %product_elements ; ) > 
<!ATTLIST product merchant id CDATA tREQUIREI» 
<! ELEMENT productid (#PCDATA)> 
<!ATTLIST productid type CDATA 8IMPL1ED> 
<! ELEMENT description IS PCDATA) > 

<'ELEMENT uniC (ffPCDATA)> 
<!ATTLIST unit name CDATA #REQUIRED> 

<request /products /product /quant ity> elements 

<!ELEMENT quantity (%quantity_elements; l> 

<!ATTLIST quantity number CDATA #REQUIRED> 

<! ELEMENT cost (« PCDATA) > 

<!ATTLIS? cost currency CDATA #REQUIRED> 

<?ATTLIST cost name CDATA »REQUIRED> 

<!ATTLIST cost rate CDATA #IMPL1ED> 

<•-- <response> elements 

< 'ELEMENT response (%response_elements; )> 

<! ELEMENT code (# PCDATA )> 

<!ATTLIST code type CDATA #REQUIRED> 

<! — 

<* ELEMENT description («PCDATA)> 
— > 

< 'ELEMENT rrn («PCOATA)> 

<! — <response /Options > elements — > 
<!ELEKENT options (%options_elements; ) > 
<! ELEMENT workflow (» PCDATA) > 
<!ATTLIST worlcflow id CDATA iREQUIRED> 

< /XMPx / BODYx /HTML> 
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Purcaae ID Request 

<?xml version='1.0' ?> 
<!DOCTYPE iwn > 
<! — conmenC — > 

<iwn version='0.4- Session='6d5i8aa7'7a49d8bc82303?illdd877d6931d6245"> 
<purchase> 

<requesc cype='purchaseid*> 

<auChencication cype="iwnuser"> 
<id type= • emai 1 ' >boctief as telscra . conic / id> 
<password>merchant</password> 
</authencication> 
</requesC> 
</purchase> 
</iwn> 

Purchase ID Response 
<?xml versions "i.O* ?> 
<!DOCTYPE iwn > 
<! — comment — > 

<iwn version=-0.4* Session='6d518aa77a49d8bc823037111dd877d6931d6245"> 
- specifies the id of the purchase — > 

cpurchase id='acs233d23dacad"> 

<response> 

<code cype='purchase'>128</code> 

<description>Purchase ID Successfully Assigned</description> 
<options> 

<worXf low id= • 2 " >Logout< /workf low> 
<workf low id="4 •>Purchase</workf low> 
<workflow id="7»>Transaction Status< /workf low> 

</options> 
</response> 
</purchase> 
</iwn> 
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PttTchaae request 
<?xini version="1.0" ?> 

<!DOCTYPE iwn (View Source tor fuiJ dQctype,..)> 
comment — > 

<iwn version=-0.4- session=-6d518aa77a49d8bc823037111dd877d6931d6245"> 



if this purchase should be automatically processed 
set the authorize flag cc true^ 
from a POS unit this will almost always be true, 
but from a web client, the authorization will 
most likely be false, to allow the merchant to 
manually authorize the purchase via email /messaging. 

— > 

<purchase id="acs233d23dacad* authorizes- true •> 
<request type= "purchase "> 
<! — 

AUTHENTICATION 

— > 

<authentication type="iwnuser*> 
<id type= ' email ■ >bottlef aste telstra . com< / id> 
<password>merchan t < /password> 
</authentication> 

<! — 

SOURCE 
Valid Types: web, pos 
the source of this document 
— > 

<source> 
<pos> 

<terminalid>12346</tenninalid> 
</pos> 
<! — 

If source is web, <client> specifies the 

customers IP address. <server> indicates 

the IP address of the web server serving 

the request. 

IP/FQDM are both valid. 

<web> 

<client>203 .122 . 33 . l</client> 
<server>www. indwide . net< /server> 
</web> 
— > 

</source> 
<! — 

DELIVERY DETAILS 

Valid Types: address, pos Ipoi.nt of sale) 

If delivery details are absent, and source is web 

they will try to be looked up via the sessionid 

If delivery details are <pos>, it is assumed the 

goods were taken from point of sale. 

<delivery> ^ 

<address> 

<unit></unit> or <level></level> are optional 

<number>< / number > 

<street></street> 

<suburb>< / suburb> 

<city></city> 

<state></state> 

<country>< /country> 

<pos tcodex /pos tcode> 

</address> 

</delivery> 

or 

<delivery> 

<pos/> 

</delivery> 

<delivery> 
<pos /> 
</deiivery> 
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<!-- 

PAYMENT DETAILS (SENSITIVE) 
Valid types: card, iwnuser 

Note the iwnuser id may be looked up using the 
5 card number for other projects such as loyatly. 
— > 

<payment> 

<card> 

<naiiie>Card N. Holder</naine> 
10 <nuinber>456400000000</nuinber> 
<! — 

month can be the following: 

01, 02 11, 12 

1. 2 11. 12 

IS January. February, ...» November, December 

Jan. Feb Nov. Dec 

year can be the following: 

00. 01 98. 99 (+2000) 

2000. 2001 2998, 2999 

20 

<expiry month='01' year='01" /> 
<!-- 

valid account types are credit, 
cheque, savings, etc. will be supported 
25 in a later release. 
--> 

<accoun t>credi t< / account> 
</card> 
<!-- 

30 Alternately, <iwnuser> can be used to lookup the 
credit details via the IWNUserlD or email 
<iwnuser> 
<id>3</id> 

<password>foo</password> 
35 </iwnuser> 
or 

<iwnuser> 

< ema i 1 > f oo(?bar . com< / ema i 1 > 

< pas s word> f oo< / pas sword> 
40 </iwnuser> 

— > 

</payinent> 

<!" 
PRODUCTS 

45 Optional. The <products> collection may be ommitted entirely 
if desired. 
— > 

<products> 

<!-* 

50 Each product must contain a product id and 

a merchant id. This allows for multiple products /merchants 
per purchase request {example: Virtual Mall) 
— > 

<product merchantid="99*> 
55 <prqductid type=-EAN->lllllllllllll< /product id> 

<l— 

name and description are optional 
— > 

<name> f oo< /name> 
60 <description>600gram bar of foo</description> 
<! — 

unit and unit name refer to the quantity 
of the product, 
examples : 
65 1 X 600ml milk 
<id>l</id> 

<description>milk</description> 
<unit names "ml *>600</unic> 
<quanticy nu2ttbers'i*>. . .</quantity> 
70 3 X 3kg bag of oranges 
<id>2</id> 

<description>3k9 bag of oranges</description> 
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<unit name='kg''>3</unic> 

<quanticy nuinber=-3-> . - .</<Juantity> 

--> 

<unit name=''Jcg'>l</unit> 
5 <!- 

currency codes conform to ISO 4217 



- -> 



10 <quancity nuinber=*2"> 

cost tags are optional within <guantity/> tags. 
There may be an arbitrary amount of cost tags here. 
They are not used for calculation of price at all. 

15 They are solely used for reporting /accounting. 

It is up to the merchants discretion which costs 
they send with each purchase request. 
Cost najnes are arbitrary. , 
coses within the <ciuantity> tag refer to each unit, 

20 not to the group of products. 



25 



35 



-> 



<cost nan>e='cosf currency='AUD'>100</cosc> 
<cost name= -pretax- currency=-AUD->200</cosC> 
<cost name=-8ale- currency=-AOD->220</cost> 
<cost name=-sta£fdiscount- currency=-AUD- race=-10% >20</cost> 
<cosc ^=-dth-£ee- currency=-AUD- race=-10%->20</cosc> 
<cost ^=-GST- currency--AUD- race=-l0%->l6</cost> 
<cost name=-subtotal" currency=-AUD->l76</cosc> 
</quanticy> 

^ There may be an arbitrary nu»ber of <cost> tags within each 



<product> tag 

For a description, see above 



rvA ™ v»w-w-r . 

cost tags here are also optional. . • rvio <»nrire 

cost tags inside <product> refer to the pricing of the entire 
<guantity> of products. 



— > 



<cost name=-foo- currerxy='AUD->10</cost> 
<cost name=-quantitytotal- currency=-AUO->362</cost> 
40 < /product > 
</products> 

COST 

45 cost outside the <products> tree is mandatory. 

This value is the actual value that will be passed 
CO the financial switch for credit/debit. 



50 <cost name=-total- currency=-AUD->362</cost> 
</request> 
</purchase> 
</iwn> 
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Pttrcfaase Reaponge 

<?xml versions •1.0" ?> 

<!DOCTYPE iwn (View Source for full doctype.. J> 
<! — 

IWN Purchase Response Sample Docixment ^ ^ „ 

version: $Id: purchase-response. xml.v 1.4 2000/06/05 03:05:08 dth Exp S 

Milestone: 4 

Version corresponds zc the Milestone release, 
id corresponds to the Purchase ID. 

'<iwn version=-0.4- session=-6d518aa77a49d8bc823037illdd877d6931d6245-> 

<purchase id='acs233d23dacad"> 

<response> 
<code type= "purchase" >0</code> 
<description>Purchase Success ful</description> 
<rrn>iwnO03211412551l234</rrn> 



- Request Transaction Status 

- Request Purchase Authorization 

- Request Purchase Reversal 

- Logout 



<options> 
<workf low id= * 2 • >Logout< /workf low> 
<workflow id='5'>Purchase Authorize< /workf low> 
<work£low id='6'>Purchase Reversal < /workf low> 
<workflow id='7->Transaction Statu5< /workf low> 
</option5> 
</respon5e> 
< /purchase> 
</iwn> 
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Preface 

This document is provided to assist a developer in utilising the IWN Transaction SDK in 
the development of a client application that is to perform transactions using the IWN 
Transaction System. 

Associated Documentation 

This document can be used in conjunction with the IWN Engine Client Specifications. 
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Overview 

The IWN Transaction SDK consists of an ActiveX EXE containing several classes that 
are used to collect, format, verify and send transactions to the IWN Transaction System, and 
receive, parse and provide the results of those transactions to a calling application. 

Communications 

The IWN Transaction Classes communicate with the IWN Server over TCP/IP using 
specially formatted documents for transferring informaiion. Each Transaction type may perform 
any number of Transactions with the IWN Server. For a Transaction the flow of information is 
as follows: 

- A TCP/IP Connection is established between the Client and the IWN Server. 

- The Client sends a Request Document to the IWN Server. 

- The IWN Server sends a Response Document to the Client. 

Sessions 

The IWN Transaction Systems utilises Session management to provide tracking, 
reconciliation and to ensure the integrity of Transactions. 

When a Client creates an instance of the Session Object^ it can call the Logon method 
which will request a Session from the IWN Server. Once the IWN Server has issued the Client 
with a valid Session, the Client can use that Session to send Transactions. 

A Client uses the Merchant Details provided to identify and authorize itself to the IWN 

Server. 

Transactions 

The following Transaction types are currently supported: PURCHASE, REVERSAL, 
AUTHORIZE and STATUS 

Sample Session 

Here is a typical usage scenario. 

This section refers to code in the iwnExample Visual Basic project distributed with the iwn 
component. 
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- The calling applicalion will typically create an IWN session object when it loads or 
initialises. 

- It will then set the following Session object properties: 

o ServerAddress 
o ServerPort 

- The calling application may then ensure it has contact with the IWN engine and call the 
Session objects Login method, passing the Merchants Usemame and password. 

- The Login method should return true or false and set an error depending on whether the 
Login was successful. The application may wish to rectify any problems and try the 
login again should the login have failed. 

- It the Login method returns True, the the Merchant has been issues a valid session and 
may now conunence with committing transactions. 

- To perform a transaction, the calling application would execute the Session objects 
Transaction collections Add method, which will return a valid transaction object. When 
the Add method is called, the IWN transaction server is contacted for a valid transaction 
number to use. If this failed, then the Add method will return null. The calling 
application should check the validity of the Transaction object returned by the Add 
method before it attempts to use it. 

- When it has obtained a valid transaction object, the calling applicalion must then set the 
following properties of that transaction, before the transaction can be conunitted: 

o CardExpiryMonth 

o CardExpiryYcar 

o CardName 

o CardNumber 

o CurrencyType 

- The calling application can then create Product objects within the Transaction object to 
represent the difference products, prices and quantities for the transaction. The calling 
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application can add a Product object to the Transaction by calling the Transactions 
objects Products collection Add method. The Add method will return Product object, 
whose properties can be set to indicate the desired product, quantity and unit cost. 

- The calling application can repeal this step to add any number of products to the 
transaction before it is commited. 

- Before the Transaction is committed, the calling application can adjust the amount for 
the u^saction by setting the Transaction objects Amount propeny. This allows for 
adjustments such as discounts, part payments or credits. If there are no products added, 
the calling application must explicitly set the Transaction objects Amount propeny or 
the Transaction will have the default value of 0. 

- When the calling application wishes to commit the u-ansaction, it can simple call the 
Transaction objects Send method, which will send the transaction to the IWN engine, 
and retum'Truc if successful or False if the u-ansaciion failed. 
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Terminology 

IWN Server 

The IWN Transaction Server. 
Client 

The calling application, in which objects of the IWN Transaction Classes arc created. 
Transaction 

A single network transaction. Indication the sending of data to the IWN Server and the 
receipt of information from the IWN Server. This DOES NOT indicate a financial transaction. 
A transaction is considered complete when a valid Request Document has been sent to the IWN 
Ser\'er and a valid Response Document has been received from the IWN Server 

Request Document 

The IWN Transaction Classes use a special message format for transferring information 
between a Client and the IWN Server. As in a Transaction, a document is sent and a document 
is received. A document transferred FROM the Client TO the IWN Server is a Request 
Document. 

Response Document 

As with the Request Document, the Response Document is sent FROM the IWN Server 
TO the client after the server has received and processed a valid Request Document. 

Purchase 

A Purchase is a type of credit transaction. Within the scope of the IWN Transaction 
SDK it is considered a virtual transaction. A Purchase may constitute several Transactions^ 
depending on the requirements of the Purchase. (See Transaction) 

Reversal 

A Reversal is a type of credit U^saclion. (See Purchase) 
Session 
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Objects 
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Session Object 

Parent: (none) 
Children: Transactions 
Default Property: (none) 
Properties 




Comments 

A single sassio. objea is a^. i.'s pa^ne.- are se, and .h» login meftod is called. 
Once a successful login 1»s occuncd *e session oKjec. can be used .0 c.a.e .ansacuon 
objecs. Tnns^uon objec. can». Cead should no.) *e c«a.ed if is n« curen, va.,d 
session, or if ibe session object is not connected to a valid session. 
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Transactions Collection Object 



Properties 









Count 


String 


Read Only 


Item 


Object 


Readonly 


Methods 






Add 


(none) 


Delete 


Index as Variant 



Comments 



The Transactions Collection object exists within the session object and holds all the 
Transaction objects that have been created within the session. The Transactions Collection 
object can be enumerated in For Each statements to retrieve each Transaction object in 
sequence. 
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Transaction Object 
Properties 



Amount 


i£56 ^ 


Read/Write 


CardExpiryMonth 


Integer 


Read/Write 


CardExpiryYear 


Integer — 


Read/Write 


CardName 


String 


Read/Write 




String 


Read/Write 


Code 


Integer — 


Read Only 


CurrencyType 


iwnCurrencyType Integer 


Read/Write 


Description 


String 


Readonly 


Products 


Products Collection Object 


Read Only 


RRN 


String 


Read/Write 


SessionID 


String 


Read Only 


SystemTracc 


Integer 


Read Only 


TransactionlD 


String 


Read Only 



Methods 




Comments 

A Transaction Object is created within the Transactions Collection object when there is 
a vaUd session present in the Session object. A Transaction object is created, its properties set, 
and the send method is called. Transactions will exist until explicitly killed or unUl as session 
has ended. 
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Products Collection Object 
Properties 




Methods 



(none) 



Index as Variant 



Comments 

The Products Collection object exists within a Transaction object and holds all the 
Product objects that have been created within the transaction. The Products Collection object 
can be enumerated in For Each statements to retrieve each Product object in sequence. 
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Product Object 



Properties 









Amount 


Long 


Read/Write 


CurrencyType 


iwnCurrenc\Type Integer 


Read/Write 


MerchantID 


String 


ReadAVrite 


ProductID 


String 


Read/Write 


Quantity 


Long 


Read/Write 



Methods 



Comments 



A Product Object is created within the Products Collection object in a valid Transaction 
Object. A Product object is created, its properties set. The product details are issued with the 
Transaction when the parent Transaction object is committed. 

Products will exist until explicitly killed or until the parent Transaction Object has 
terminated has ended. 
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Properties 
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MerchantID Property (Session Object, Transaction Object, Product Object) 
The MerchantID property contains the Merchant ID for the Session, Transaction or 
Product. 

Syntax 

objSession.MerchantID 
Data Type 

String 

Comments 

The MerchantE) property can be set before an active session. Unless explicitly set. 
Merchaniro's for Transaction and Product objects will assume the value of Merchant© in the 
Session object. 

Example 

With objSession 

.MerchantID = "99" 
End With 
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Route Property (Session Object) 

The Route property is used to specify a gatevray IP address to use when sending 
transactions. 
Syntax 

objSession.Route 
Data Type 

String 

Comments 

Setting the Route property will modify the system routing table by adding a stauc route 
,0 the IP address or hostname specified by the ServerAddress property via the IP address 
specified in the Route property. The Route property can be set any number of times during the 
life of an active session and the next Transaction to be commited will use the route specified. 

If the IP address supplied with the Route property does not exist as a valid interface, the 
routing table will not be modified but the Route property will retain the IP address given. 
Currently there is no way to determine if a call to the rouung table was successful, but future 
vereions will support notification of the Route entry. 

Example 

ms code mil add a route to the system routing table sp^^yj^Vhat all traffic for 
iymengine.indwide.net should go through the interface 192.168.0.10 
With objSession 

;ServerAddress = "iwnengine.indwide.net" 
.Route = "192.168.0.10" 
End With 
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Server Address Property (Session Object) 

The ServcrAddress property specifies the address of the IWN engine server that the 
Session should communicate with. 

Syntax 

objSession^erverAddress 
Data Type 

String 

Comments 

The ServcrAddress property is required before the Session objects Login method can be 
called. The ServcrAddress property can (read should) only be set once before the session is 
validated. Setting this property during a valid session will not (read should not) take effect until 
the Session is terminated and a new Session is created. 

Example 

With objSession 

.ServcrAddress = "iwnengine.indwide.net" 

.ServcrPort = 5005 
End With 
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ServerPort Property (Sessiort Object) 

Sets ihe TCP port used lo communicate with the IWN engine server specified with the 
ServerAddress property. 

Syntax 

objSession.ServerPort 
Data Type 

String 

Comments 

See ServerAddress Property (Session Object) 

Example 

With objSession 

.ServerAddress = "iwnengine.indwide.net'* 

.ServerPort = 5005 
End With 
See Also 

ServerAddress Property (Session Object) 
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SessionID Property (Session Object) 

The SessionID property contaii>ts ihe Session ID for the active session. 

Syntax 

obiSession-SessionlD 
Datatype 

String 

Comments 

The SessionID property is automatically assigned a value when a session is created by 
executing the Login method. Functionality has been provided to set the SessionID property of a 
Session object to support the future ability to resume sessions between invocations of the 
Session object. This functionality is not currently available and setting the Session© before or 
after a session login will not (read should not) affect any transacuons that are committed withm 
the scope of the session. 
Example 
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TerminallD Property (Session Object) 

The TerminallD property contains the TerminallD for the session. 

Syntax 

objSession.TerminaUD 

Data Type 

String 

Comments 

The TemunallD is required before a valid session can be obtained. 

Example 

With objSession 

.TenninalD = 'T1001" 
End With 
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Transactions Property (Session Object) 

The Transactions Property returns a single Transaction object or a Transactions 
collection object. 

Syntax 

Set objTransactions = objSessionJnns*dcX\ons 
Set objTransaction = objSession.Tr^ns^ctionsiindex) 
Set objTransaction = objSes5ionJr2kfisaciions(name) 
objSession 

Object. A Session object. 
objTransactions 

Object. A Transactions collection object. 
objTransaction 

Object. A Transaction Object. 

index 

Long. Specifies the number of the Transaction within the Transactions collection. 
Ranges from 1 to the value specified by the Transactions collection's Count Propery. 

name 

String. A Transaction ID. 
Data Type 

Object (Transaction or Transactions Collection) 

Comments 

Example 
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Amount Property (Transaction Obiect) 

The Amount property contains the amount for the .ransacuon. 

Syntax 

objSession.Amount 
Data Type 

Long 

Comments 

— U «p«e»«. in ^ 0. c^nc, Co- SAUD. *e 

associ^ea P««W objccu. The An,o»n. prop.,., w,n(.ead shou 

Example 

With objSession 

.Amounts 133414 

End With 
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CardExpiryMonth Property (Transaction Object) 

The CardExpiryMonth property represents the 2 digit expiry month of the credit card 
specified by the CardNumbcr property. 

Syntax 

objSession.CardExpiryMonth 

Data Type 

Integer 

Comment 

The CardExpiryMonth Propeny accepts and Integer in the range 1-12 represeniing the 
2 digit month of the expiry date on a credit card. If the value given when setting the 
CardExpiryMonth property is outside this range, then the property defaults back to 0 and the 
transaction will return an error indicating an invalid expiry dale when an attempt is made to 
commit the transaction. 

Example 

With objSession 

.CardExpiiyMonth = 4 

.CardExpiryYear = 0 
End With 
See Also 

CardExpiry Year Property 
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CardExpiryYear Property (Transaction Object) 

The CardExpiryYear property represents ihe 2 digit expiry year of the credit card 
specified by the CardNumber property. 

Syntax 

objSession.CardExpiryYear 

Data Type 

Integer 

Comments 

The CardExpiryYear Property accepts a year value as an integer in both 2 and 4 digit 
format. If the specified Integer is between 0 and 99 it is assumed that this represents a 2 digit 
date between the year 2000 and 2099. If the specified Integer is between 2000 and 2099 it is 
assumed that this represents a 4 digit date between the year 2000 and the year 2099. 

Sec Also CardExpiryMonth Property for handling of values outside the accepted ranges. 
Example 

See CardExpiryMonth Property. 
See Also 

CardExpiryMonth Property. 
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CardName Property (Transaction Object) 

The CardName property contains the full name of ihe card holder of the credit card 
specified in the CardNumber property. 

Syntax 

objSession.Csirdfizme 
Data Type 
String 

Comments 
Example 
See Also 

CardNumber Property (Transaction Object) 
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CardNumber Property (Trartsaction Object) 

^ CardNu^ber property con..s .e number of 0.e credU card . 
referenced by the trsmsaction. 
Syntax 

obfrransactionCardHumher 

Data Type 

String 

Comments 

T^C^»n,b.rp»fe«yis«,ui«dbef«a«=ma«ionca„b=conu*«.. 
Example 

0000 that expires on January 2000, 
With objTransaction 

.CardNumber = "4502000000000000?' 

.CardName = "John Citizen" 
.CardExpiryMonth = 1 
.CardExpiryYear = 0 

End With 
See Also 

CardName Property (Transaction Objea) 
CardExpiryMonth Property (Transaction Object) 
CardExpiryYear Property CTransacuon Object) 
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Code Property (Transaction Object) 

The Code property returns the response code received from the IWN Engine after a 
Transaction has been commiiied. 

Access 

Read Only 
Syntax 

objTransaction.Code 

Data Type 

bteger 

Comments 

Example 

See Also 

rWN Engine Error and Return Codes 
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CurrencyType Property (T ransaction Object) 

The CurrenqrType property coniains the the Currency type of the amount specified in 
the Amount property. 

Access 

Read/Write. 
Syntax 

ObjTransaction.CumncyType 
Data Type 
iwnCurrencyType 
Comnnents 

The value contained in the CurrencyType property represents a value from the 
iwnCurrencyType enumerator. 

Exannple 

The following example would set the result in a Transaction for $100.00 Australia Dollars. 
With objTransaction 

.CurrencyType = AUD 

.Amount = 10000 
End With 
See Also 

Amount Property (Transaction Object) 
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Description Property (Transaction Object) 

The Description property returns the description property received from the IWN engine 
after a transaction has been conunilied. 
Access 
Read Only. 
Syntax 

objTransQCtionDesznption 

Datatype 

String. 

Comments 

Example 

Dim sDescripiion As String 
sDescription = objTransaction.Descripiion 

See Also 

Code Property (Transaction Object) 
RRN Property (Transaction Object) 
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Products Property (Transaction Object) 

The Products property returns a single Product object or a Products collection object. 

Access 

Read Only. 

Syntax 

Set objProductss = objTransa€tion,?Toducts 
Set objProduct = objTransaction.?toducts{index) 
Set objProduct = objTransaction.?roducis{name) 
objTransacnon 

Object. A Transaction object. 
objProducts 

Object. A Products collection object. 
objProduct 

Object. A ProduciObject. 

index 

Long. Specifies the number of the Product within the Products collection. Ranges 
from 1 to the value specified by the Products s collection's Count Property. 

name 

String. A Product ID. This can be identified as the Product objects ProductID 

property. 

Data Type 

Object (Product or Products collection) 

Comments 

Example 

The following example would retrieve the Product object for a product with a product id 
of 131001 from the Products collection in the Transaction object. 
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Dim objProduct As Product 

Dim objTransaction As Transaction 

Set ObjProduct = objTransaction.Froducisri3100r') 

Produces eduction and display the Product objects ProductID property. 
Dim objTransaction As Transaction 
Dim iCount As Integer 

For iCouni = 1 To objTransaction.Products.Count - 1 

Debug.Print objTransaction.Products(iCount).ProductlD 

Next 

See Also 
Product object. 
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RRN Property (Transaction Object) 

The RRN propeny returns ihe receipt number of the response received from the IWN 
engine after a transaction has been committed. 
Access 
Readonly. 
Syntax 

obfTrattsactionJiBii 

Datatype 

String. 

Comments 

Example 

Dim sRRN As String 
sRRN = objlransaction-RRN 
See Also 

Code Property (Transaction Object) 
Description Property (Transaction Object) 
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SessionID Property (Transaction Object) 

The SessionID property returns the Session ID of the parent session under which the 
Transaction was created. 
Access 
Read Only. 
Syntax 

objrransaction.S^ionU) 

Date Type 

String 

Comments 
Example 

See iwnexample example. 
See Also 
Session object 

SessionID Property (Session Object) 
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SystemTrace Property (Transactioit Object) 
The SystemTrace property returns the system 
the IWN engine after a transaction has been committed. 

Access 

Readonly. 
Syntax 

ofe/TfanaflcHon-SystemTrace 

Date Type 
Integer. 
Comments 
Example 

Dim iSystemTracc As Integer 
•SystemTrace = objTransaction.SystemTrace 

See Also 

Code Property (Transaction Object) 
Description Property (Transaction Object) 
RRN Property (Transaction Object) 



trace code of the response received from 
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TransactionID Property (Transaction Object) 

The TransacUonE) property returns the transaction id of the transaction object. 

Access 

Read Only. 

Syntax 

objTransaction.Tr2itiS2iCtionlD 

Date Type 

String. 

Comments 

The TransactionID property is automatically assigned by the IWN engine through the 
Session object when the Transaction object is created. After the transaction has been created, 
the transaction id cannot be changed. 

Example 

See Also 
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Count Property (Transactions Object) 

Returns ibe number of items in the Transactions collcciion. 

Access 

Read Only. 

Syntax 

objTransactions. Count 
Date Type 
Long. 

Comments 
Example 
See Also 
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Count Property (Products Object) 

Returns the number of items in the Products collection. 

Access 

Readonly. 

Syntax 

objProducis.Connt 
Date Type 

Long. 

Comments 
Example 
See Also 
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Item Property (Transactions Object) 

Returns a Transaction object from a Transactions colleciion. The Item property is the 
default property of the Transactions object. 

Access 

Read Only 
Syntax 

ob/rransacthnsltemiindex) 

objTransactionsJiem(key) 

index 

Long. A number in the range of 1 to the value of the Transactions object Count 

property. 
key 

String. The transactions id of an individual Transaction object. 
Date Type 

Object. Transaction object. 
Comments 
Example 
See Also 
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Item Property (Products Object) 

Returns a Product object from a Products collection. The Item property is the default 
property of the Products object. 

Access 

Read Only 
Syntax 

objProductsJtemiindex) 

objProduc!s.ltem{key) 

index 

Long. A number in the range of I to the value of the Products object Count 

property. 
key 

Suing. The product id from an individual Product object. 
Date Type 
Object. Product object. 
Comments 
Example 
See Also 



Sobstitate Sheet 
(Biile26)RO/AU 



PCT/AU00A)O73O 

WO 01/01300 

76 



Methods 
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Login Method (Session Object) 

The Login method contacts the IWN engine and requests a session in which to transfer 
transactions. 

Syntax 

objSessionljogmiEmaii Password) 
objSession 

Required. Object. Session Object. 

Email 

Required. String. Email address, also referred to as usemame. 
Password 

Required. String. Password associated with the supplied usemame. 
Return Type 
Boolean 
Comments 

The Login method contacts the IWN engine, requests a session and retrieves a session 
id. If the Login method is successful, the Login method will return True. If the Login method 
cannot obtain a session id for any reason it will return False and set an error. 

Example 

See Also 

Logout Method (Session Object) 
SessionID Propeny (Session Object) 
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Logout Method (Session Object) 

The Logout method closes a session created by the Login method and clears any stored 
session information. 

Syntax 

objSessionLogoui 
Return Type 
Boolean 
Comments 

The Logout method will close a open session and clears all session related data. 

Example 

See Also 

Login Method (Session Object) 
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Add Method (Transactions collection Object) 
Adds a Transaction object to a transactions collection. 
Syntax 

Set obfTransaction = obfTransactionsAAd 
objTransaction 

„0«Aad«-«»<'"-«Tr«e.co«ains*.«wTr»»«U»<*i«.. 

obfTransaciions 

Required. The Transactions collection object. 

Return Type 

Object. Transaction object. 

Comments 

Example 
See Also 
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Delete Method (Transactions Collection Object) 

This method has been disabled and is under review. It should not be utilised in a calling 
application. 

Deletes a Transaction object from a Transactions collection object. 

Syntax 

Return Type 

Comments 

Example 

See Also 
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Send Method (Transaction Object) 

Commiis a iransaclion to the IWN engine. 
Syntax 

objTransactionSaid 
Return Type 
Boolean. 
Comments 

Tl,e Send method queues a transaction for sending to the IWN engine. If the Send 
method was able to successfully que the transaction, it will return True. If the Send method .s 
unable to queue a transaction, it will return False and set an error. The Send method .s 
asynchronous, a return value of True does not md^cate that the transaction was sent 
successfully, it only means that the transaction was successfully queued. When a transaction .s 
sent the Send method wiU raise the Response event in its parent Session object, indicaung 
whether the transaction was successfully sent. If the Send method successfully transmtts the 
«on to the IWN engine and receives a valid response. ,t will set the values of the Code, 
Description and SystemTrace properties to those received in the response. 

Example 
See Also 
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Add Method (Products Collection Object) 
Adds a Product object to a products collection. 
Syntax 

Set objProduct = objProductsAAd 
objProduct 

If the Add method returns True, contains the new Products object. 
objProducts 

Required. The Products collection object. 
Return Type 
Object. Product object. 
Comments 
Example 
See Also 
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Delete Method (Products Collection Object) 

This method has been disabled and is under review. It should not be utilised in a calling 
application, 

Dcleics a Product object from a Products collection object. 

Syntax 

Return Type 

Comments 

Example 

See Also 
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Enumerations 
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Error Codes 









ERR SUCCFSS 


0 


Qii/»f»pcc 


FRR TRANSAmON 


llAA/ 


1 iicic wd5 d gcnciaJ 
transaction error 


ERR INCOMPLETE REQUEST 


1001 




ERR INVALID REQUEST 


1002 




ERR INVALID RESPONSE 


1008 




ERR REPLY TIMEOUT 


1009 




ERR_SEND_FAILED 


1010 




ERR_IN_PROGRESS 


1900 




ERR.SOCKET 


2000 




ERR_SOCKET_CONNECT_TIMEOUT 


2001 




ERR_SOCKET_NOT_READY 


2002 




ERR_1NVAL1D_SERVER_DETAE^ 


2003 




ERR_SOCKET_EVENT_UNKNOWN 


2100 




ERR.SYSTEM 


7000 
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Claims 

1 . An eiectfonic commerce system comprising: 

a series of poim of sale tenninals providing for point of sale tnfonnatton handling of a number of businesses: 

an imerconneccion network interconnecting the point of sale temiinals to a central database facility: 

a central database facility for storing information about each of said businesses for access by the operators of said 
poim of sale terminals: and 

a series of service providers interconneaed to said cemral database facility for meeting requests issued by said point 
of sale terminals. 

2. A system as claimed in claim 1 funher comprising: 

a series of suppliers interconneaed lo said cemral database facility for meeting requests issued by said point of sale 

terminals. 

3. system as claimed in claim 2 wherein said suppliers include at least one of: 
an impon/expert agent; a warehousing agent or a producer. 

4. A system as claimed in any previous claim wherein said service providers irtclude one of: 
a third party information vendor providing information upon request: 

a financial transaction vendor providing financial transaction authorisation upon request; or 
an order fulfilment vendor providing order fulfilment upon request. 

5. A system as claimed in any previous claim wherein said point of sale terminals include local database 
information and programs which are downloaded on demand from said central database fadlily. 

6. A system as claimed in any previous claim wherein the point of sale terminals to interact with the said main 
remote data-store wherein any changes to the local datastore are periodically updated to the main datastore. and where relevant 
produced as pan of the clienis web page. 

7. A system as claimed in any previous claim funher comprising access means for accessing the datastore as a 
member of the general public using a web browser and funher means for communicating in a timely manner direaly to the 
Poim of Sale merchant and if that merchant is there then commuiricatirig with the merchant in actual ume. 

8. A system as claimed in any previous claim wherein said request are trannutted in Ihe form of XML 
documents or the like to and from said central database facility. 

9. A system as claimed in any previous claim funher comprising a series of user mobile data emry devices 
which interact widi said point of sale terminals in the authorization of a transaction. 

la A system as claimed in claim 9 wherein sah) mobile data entry device include one of WAP enabled phones, 
mobile phones or bluetooih connected devices. 

11. A system as claimed in any previous claim further comprising a separate interacdon unit for users to inteiaa 
widi said central database facility for the viewing of transaction stalislies associated wid) said system. 

12. A system as claimed in claim 1 1 wherein said viewing of transaction statistics includes utilising OLAP 
facilities on said central database. 
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13. A system as claimed in any previous claim wherein requests are provided by a software development kit 
applications programming interface. 

14. A system as claimed in any previous claim wherein actions undertaken by said database facility arc in the 
form of workflow steps executed by the faciUty. 

15. A system as claimed in claim 14 wherein said workflow is spawned by the template structure of said 

request. 

16. A system as claimed in any previous claim further comprising an interaaive graphical database for 
interacting with said central database facility. 

17. A system as claimed in any previous claim wherein nnihiple centralised database facilities are provided and 
interact with one another to perform functions. 

1 8. An electronic commerce system substantially as herein before described with reference lo ihe accompanying 

drawings. 

19. A method of conducting commercial transaaions substatamially as hereinbefore described with reference to 
Fig. 3 of the drawings. 

20. A method of conducting electronic commerce substantially as hereinbefore described wiih reference to the 
accompanying drawings. 
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